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CHAPTER  I 


INTRODUCTION 


Programming  begins  with  tha  spaeificatlon  of  what  tha  desired  program  should  do;  the 
programmer's  job  la  to  develop  an  exacutable  program  satisfying  those  specifications.  The 
goal  of  automatic-programming  research  Is  to  formalize  the  methods  and  strategies  used 
by  programmers  so  that  they  may  be  incorporated  in  an  automatic,  or  interactive, 
programming  environment. 

While  most  automatic-programming  research  has  focused  on  the  creation  of  programs 
ex  nihilo,  very  little  of  this  work  concentrates  on  applying  past  experience  to  new 
problems.  Typically,  a  programmer  directs  more  of  his  effort  at  the  modification  of 
programs  that  have  already  been  written  than  at  the  development  of  original  programs. 
The  evolutionary  cycle  of  a  program  includes  debugging,  changes  to  meet  amended 
specifications,  and  extensions  for  expanded  capabilities.  Even  when  nominally  engaged  in 
the  construction  of  a  new  program,  the  programmer  is  constantly  recycling  "used" 
programs  and  adapting  basic  principles  that  have  already  been  Incorporated  Into  other 
programs.  Ideas  of  general  applicability  are  abstracted  into  subroutines  or  programming 
techniques  and  then  applied  to  specific  problems  at  hand. 

In  this  research,  we  have  attempted  to  emulate  the  evolutionary  aspects  of 
programming  in  the  context  of  an  automatic  program-development  system.  We  have 
formulated  techniques  of  program  modification,  whereby  a  given  program  that  achieves  one 
goal  can  be  transformed  into  a  new  program  to  achieve  a  different  goal.  The  essence  of 
the  approach  is  to  find  an  analogy  between  two  sets  of  specifications,  those  of  a  program 
that  has  already  been  constructed  and  those  of  the  program  that  we  desire  to  construct. 
This  analogy  is  then  used  as  the  basis  for  transforming  the  existing  program  to  meet  the 
new  specifications.  Program  debugging  is  considered  as  a  special  case  of  modification:  if  a 
program  computes  wrong  results,  It  must  be  modified  to  achieve  the  Intended  results. 

Program  modification  Is  not  the  only  manner  in  which  a  programmer  utilizes  previously 
ecqulred  knowledge.  The  human  programmer  improves  with  experience  by  assimilating 
various  programming  methods  that  he  encounters,  and  judiciously  applying  the  learned 
Ideas  to  new  problems.  After  coming  up  with  several  modifications  of  his  first  "wheel",  he 
is  likely  to  formulate  for  himself  (and  perhaps  for  others)  an  abstract  notion  of  the 
underlying  principle  and  reuse  it  In  new,  but  related,  applications.  Program  schemata  are  a 
convenient  form  for  remembering  such  programming  knowledge.  A  schema  may  embody 
basic  programming  techniques  and  strategies  (e.g.  the  generate-and-test  paradigm  or  the 
binary-search  technique)  and  contains  abstract  predicate,  function,  and  constant  symbols. 
In  terms  of  which  Its  specification  Is  stated. 
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The  abstraction  of  a  set  of  concrete  programs  to  obtain  a  program  achama  and  the 
instantiation  of  abatract  schemata  to  solve  concrete  problems  may  be  viewed  from  the 
perspective  of  modification  techniques.  This  perspective  provides  a  methodology  for 
applying  old  knowledge  to  new  problems.  Beginning  with  a  set  of  programs  sharing  some 
basic  strategy  and  their  correctness  proofs,  a  program  schema  that  represents  the 
embedded  technique  Is  sought.  Preconditions  for  the  schema's  applicability  are  also 
derived  from  the  correctness  proofs.  The  schema's  abstract  specification  may  then  be 
compared  with  a  given  concrete  specification  and  an  Instantiation  found  that,  when  applied 
to  the  schema,  yields  a  concrete  program.  If  the  Instantiation  satisfies  the  preconditions, 
then  the  correctness  of  the  new  program  Is  guaranteed. 


Extending  a  program  to  satisfy  additional  specifications  is  another  form  of  program 
modification.  Techniques  are  required  to  construct  code  that  extends  the  incomplete 
program  to  achieve  the  remaining  specifications,  while  ensuring  that  the  original 
specifications  continue  to  be  satisfied.  Modification  based  on  analogy  and  extension  can 
be  combined  to  solve  a  given  problem.  The  analogy  between  a  new  problem  and  a  given 
program  may  only  indicate  how  to  achieve  part  of  the  specified  goal;  the  transformed 
program  is  then  extended  to  achieve  the  remainder. 

Sometimes,  In  the  course  of  modifying  a  program  or  instantiating  a  schema,  it  may  turn 
out  that  a  program  segment,  e.g.  a  loop  Initialization,  must  be  constructed  from  scratch. 
Top-down  synthesis  techniques  are  useful  for  this  purpose.  Beginning  with  the  specifications 
of  the  desired  segment,  the  goal  Is  to  develop  the  program  step  by  step  until  executable 
code  is  obtained.  Each  step  consists  of  rewriting  a  segment  of  the  program  in  Increased 
detail.  Since  every  step  is  transparent  enough  to  ensure  correctness,  each  partial 
program  In  the  series  Is  equivalent  to  Its  predecessor.  In  particular,  the  final  program  Is 
guaranteed  to  satisfy  the  Initial  specifications. 


A  prerequisite  for  debugging  an  Incorrect  program  Is  knowledge  about  what  the 
program  actually  does,  as  opposed  to  what  it  was  Intended  to  do.  Moreover,  various  facts 
about  a  program  are  frequently  needed  for  the  purposes  of  modification,  though  they  were 
not  supplied  by  the  programmer.  For  these  purposes,  we  devote  attention  to  the 
development  of  annotation  techniques  for  documenting  a  program  with  assertions.  Assertions 
are  a  useful  means  of  documenting  facts  about  the  Internal  workings  of  a  program;  they 
relate  to  specific  points  In  the  program  and  assert  that  some  relation  holds  for  the  current 
values  of  the  program  variables  whenever  control  passes  through  that  point.  Qlven  a 
program  along  with  Its  Input-output  specification,  the  task  Is  to  annotate  the  program 
Incrementally  with  assertions  that  explain  the  actual  workings  of  the  program  regardless  of 
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whether  the  program  Is  correct.  These  annotations  can  be  used  as  aids  in  the  debugging 
of  an  incorrect  program.  They  can  also  be  used  for  verifying  the  correctness  of  programs 
or  for  analyzing  program  efficiency.  Our  annotation  techniques  are  formulated  as  inference 
rules. 


The  techniques  of  program  manipulation  that  we  have  investigated  are  for  the  most 
part  amenable  to  automation,  and  we  have  implemented  them  in  an  experimental  system, 
written  in  QUSP.  Our  implementation  consists  of  three  parts:  modifier,  annotator,  and 
synthesizer.  The  implementation  was  meant  to  serve  as  a  proving  ground  for  ideas;  many  of 
the  examples  presented  In  this  report  have  run  successfully.  The  modifier  has,  for 
example,  modified  an  integer  square-root  program  to  compute  quotients  and  has  debugged 
an  Incorrect  real-division  program.  Our  annotator  can  generate  the  necessary  invariants 
for  these  programs,  and  for  more  complex  programs,  e.g.  selection  sort.  The  synthesizer 
has  successfully  constructed  several  complete  programs,  such  as  one  for  finding  the 
minimal  element  of  an  array,  or  for  finding  its  value. 


The  next  chapter  presents  a  general  overview  of  the  various  aspects  of  program 
modification;  their  Individual  roles  and  their  close  Interaction  are  Illustrated  in  an  account 
of  the  evolution  of  an  example  program.  The  remainder  of  this  report  is  composed  of 
chapters  on  techniques  for 

•  modification  and  debugging, 

•  abstraction  and  Instantiation, 

•  synthesis,  and 

•  annotation. 

Each  of  these  chapters  Is  largely  self-contained,  though  a  common  set  of  examples  is 
threaded  through  them.  Bibliographic  remarks  are  included  In  the  individual  sections. 
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CHAPTER n 
GENERAL  OVERVIEW 


In  this  overview  we  shall  trace  the  life-cycle  of  a  single  example  program,  in  an 
attempt  to  impart  the  overall  flavor  of  our  approach  to  program  modification,  and  to 
Illustrate  how  the  various  aspects  are  interrelated.  More  formal  treatments  of  our 
techniques  may  be  found  In  the  Individual  chapters.  This  example  Is  outlined  In  Figure  1 ;  it 
owes  its  motivation  to  Wensley  [1969]  and  DIJkstra  [1976]. 


Figure  1.  Evolution  of  a  division  program 


We  begin  with  an  Imperfect  program  to  compute  the  quotient  of  two  real  numbers.  We 
then  debug  the  program,  after  determining  enough  about  what  the  program  actually  does. 
Once  the  division  program  is  corrected,  it  Is  modified  to  compute  the  square-root  of  a  real 
number.  Underlying  both  the  division  and  square-root  program  is  the  binary-search 
technique;  by  abstracting  these  two  programs,  a  binary-search  schema  is  obtained.  This 
schema  is  then  instantiated  to  obtain  a  third  program,  one  to  compute  the  square-root  of  an 
integer.  Part  of  that  program  is  synthesized  from  scratch. 
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1.  T hi  Problem 

Consider  the  problem  of  computing  the  quotient  t  of  two  nonnegative  real  numbers  e 
and  d  within  a  specified  (positive)  tolerance  t .  These  specifications  are  conveniently 
expressed  in  a  high-level  assertion  language  In  terms  of  an  output  specification  and  an  input 
specification.  The  output  specification  states  the  desired  relationship  among  the  program 
variables  upon  termination,  in  our  case,  the  output  specification 

\c/d-z\<e 

indicates  that  the  (absolute  value  of  the)  difference  between  the  exact  value  of  c/d  and 
the  result  z  should  be  less  than  e  .  The  input  specification  defines  the  set  of  inputs  on 
which  the  program  is  intended  to  operate.  Assuming  that  we  only  wish  to  solve  this 
problem  for  the  case  where  the  numerator  e  is  smaller  than  the  denominator  d  ,  the 
appropriate  input  specification  for  the  program  Is 

0 4c<d  A  «X)  . 

We  can  express  our  goal  in  the  form  of  the  following  skeleton  program: 

I - 1 

|  Px\  begin  comment  real-eUvisio n  program  | 

|  assert  0 ic<d,  eX)  | 

j  achieve  |c/rf-z|<<  varying  z  ( 

|  end  .  j 

l _ l 

The  achieve  statement, 

achieve  |c/d-z|<e  varying  z  , 

specifies  the  relation  between  the  variables  z  ,  c  ,  d  ,  and  e  that  we  wish  to  attain  at 
the  end  of  program  execution.  The  clause 

varying  z 

indicates  that  only  the  variable  z  may  be  set  by  the  program;  the  variables  c  ,  d  ,  and  t 
contain  input  values  that  may  not  be  modified.  The  assert  statement, 

assert  03c<<f,  eX)  , 

attached  to  the  beginning  of  the  program,  specifies  what  relation  between  the  input 
variables  may  be  assumed  to  always  hoid  at  the  beginning  of  program  execution. 

An  achieve  statement  may  be  considered  as  a  "very  high-level"  programming 
construct  that  "somehow"  achieves  the  specified  relation  at  that  point  in  the  program.  It 
is  not  directly  executable;  the  task  of  the  programmer  —  be  he  human  or  machine  —  is  to 
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I  Pt:  begin  comment  ual-dlvlsion  program  j 
|  assert  0<c<rf,  «>0  | 

|  purpose  |c/d-z|<«  j 

I  co<te  j 

|  suggest  |c/d-z|<<  j 

|  end  .  | 

I _ _ I 

The  purpose  statement, 

purpose  |c/rf-z|<r  , 

is  a  comment  describing  what  the  intent  of  the  code  following  it  is.  The  statement 
suggest  |c/d-z|<< 

contains  the  programmer's  contention  that  the  preceding  code  actually  achieves  the 
desired  relation,  i.e.  the  relation  |c/rf-z|<r  holds  for  the  value  of  z  when  control  reaches 
the  end  of  the  program. 

When  an  assertion,  such  as  |e/d-zf<r ,  has  been  proved  to  hold  each  time  control 
passes  through  some  point,  then  it  is  said  to  be  an  Invariant  assertion  at  that  point.  As  long 
as  it  has  not  been  proved  to  hold,  It  is  called  a  candidate.  In  particular,  an  output  candidate, 
associated  with  the  point  of  termination,  Is  a  local  invariant  at  that  point,  if  the  final  values 
of  the  variables  satisfy  the  asserted  relation  when  the  program  terminates.  The  assertion 
Is  termed  an  output  Invariant  once  this  has  been  proved  to  be  the  case.  A  program,  then, 
may  be  considered  correct  if  there  exist  output  Invariants  that  Imply  the  output 
specification. 

For  the  problem  at  hand,  we  must  assume  that  no  general  real-division  operator  /  Is 
available,  though  division  by  an  Integer  Is  permissible.  Otherwise,  the  problem  could  be 
solved  with  a  trivial  assignment  statement 

z  :■  c/d  . 

The  reader  may  also  note  that,  were  it  not  for  the  restriction  that  only  the  variable  z  may 
be  set  by  the  program,  the  problem  could  be  solved,  for  example,  by  setting  both  z  and  c 
to  0  .  This  would  satisfy  the  specification  |e/rf-z|<«  ,  but  Is  not  the  Intended  solution. 

Now  let  us  assume  that  a  programmer  went  ahead  and  constructed  the  following 
program: 
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begin  comment  suggtsitd  division  program 
B(:  assert  0 ic<d,  t> 0 
purpose  |c/<f-z|<e 

purpose  zSc/d,  c/d<z*y,  yU 

to.y)  (0,1) 

loop  Lt:  suggest  zs</dp  e/d<x*y 
until 

if  d*(z+y):&  then  z  :>  z+y  fi 
J  :■  ?/2 

repeat 

suggest  z£c/d,  c/d<z*y,  yit 
£,:  suggest  |c/rf-z|<< 


The  comment 

purpose  xSc/d,  c/d<z*y,  yu 

Indicates  that  the  programmer's  intention  is  to  achieve  the  desired  relation  \c/d-z\<t  by 
achieving  the  three  subgoals  xSe/d  ,  c/d<x*y ,  and  yit .  Achieving  these  relations  is 
sufficient  for  \c/d-x\<t  to  hold.  To  achieve  them,  the  programmer  constructed  an  iterative 
loop  Intended  to  keep  the  first  two  relations  invariantly  true  while  making  progress  towards 
the  third.  The  Intended  loop  Invariants  are  given  in  the  statement 

suggest  zSc/rf,  c/d<z*y 

at  the  label  L, ;  they  are  first  Initialized  by  the  multiple  assignment 
<z.>)  >  (0, 1)  . 

since  both  OSe/d  and  c/d<0*l  are  implied  by  the  assumption  that  0Sc<d .  The  two 
loop-body  statements 

If  d'(x+y)£e  then  z  :■  z*y  fi 

y  :■  y/2 

are  then  repeated  until  the  test 
until  yU 
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becomes  true,  at  which  point  the  loop  is  left* 

For  the  candidates 

suggest  z<c/d,  c/d<z*y 

to  be  loop  Invariants,  they  must  hold  when  the  loop  is  first  entered  and  must  remain  true 
each  subsequent  time  control  returns  to  the  beginning  of  the  loop.  Though  we  have  seen 
that  they  do  hold  initially,  it  has  not  yet  been  verified  that  they  remain  true. 
Consequently,  It  Is  also  not  known  if  the  output  candidate  |e/rf-z|<r  Is  invariant.  In  fact, 
by  running  the  program  with  c=l  ,  d-  3,  and  #*l/3  ,  for  instance,  the  programmer  may 
discover  that  the  result  z=0  does  not  satisfy  \c/d-z\<e .  Since  these  values  for  the 
variables  satisfy  the  input  specification,  but  do  not  satisfy  the  output  specification,  the 
program  is  incorrect.  The  bug  presumably  occurred  when  the  programmer  "inadvertently" 
interchanged  the  two  statements  within  the  loop. 


2.  Annotation 

We  know  what  this  program  was  intended  to  do.  However,  before  we  can  debug  it,  we 
must  know  more  about  what  it  actually  does.  This  will  be  accomplished  by  examining  the 
code,  trying  to  extract  as  many  relations  between  the  variables  as  we  can,  and  annotating 
the  program  with  the  discovered  relations. 

Our  techniques  for  program  annotation  are  discussed  in  more  detail  in  the  chapter  on 
annotation.  There  they  are  expressed  as  Inference  rules:  the  antecedents  of  each  rule 
are  usually  annotated  program  segments  and  the  consequent  Is  either  an  Invariant  or  a 
candidate.  These  rules  have  been  implemented;  the  automatic  annotation  of  a  similar 
program  is  shown  In  the  appendix  on  implementation. 

As  a  first  step,  we  note  that  the  Input  variables  e  ,  d  ,  and  t  are  not  changed  by  the 
program.  Therefore  the  Input  assertion 

assert  0 Sc<d,  <>0 

holds  throughout  execution  of  the  program.  Such  an  assertion  is  termed  a  global  invariant 
of  the  program;  we  write 

assert  OSc<d,  eX)  in  P ,  . 


*The  loop-until-repeat  construct  we  use  is  based  on  the  suggestion  of  J .  Ote-Dahl  in  Knuth  [1974]; 
achieve  statements  were  used  by  Sussman  [1975]. 
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We  now  try  to  determine  the  range  of  the  two  program  variables  y  and  x .  The 
eseignmenta  to  y  in  the  program  Pt  are 

y  :■  I  y  y/2  . 

The  variable  y  la  Initialized  to  I  before  the  loop  and  Is  repeatedly  divided  by  2  within 

the  loop.  It  follows  that  y*l/2n  ,  where  n  Is  some  nonnegative  integer  Indicating  the 
number  of  times  that  y  has  been  halved. 

In  dealing  with  sets,  we  find  the  following  notation  convenient:  Let  .  .  .  ,i,) 

be  any  expression  containing  occurrences  of  m  distinct  subexpressions  j(,  st,  .  .  .  ,  . 
The  set  of  elements 

l  . *,>•  . Sm^m  > 

is  denoted  by 

nst.sf . sj . 

Using  this  notation,  we  say  that  y  belongs  to  the  set  I/2N  ,  where  N  is  the  set  of 
nonnegative  Integers.  Since  this  relation  holds  throughout  the  program  Pt  from  the  point 
when  the  assignment  y>  I  is  first  executed,  we  may  assert  the  global  invariant 

assert  j»el/2N  in  Pt  . 

From  this  invariant  one  can  derive  both  an  upper  and  lower  bound  on  y  .  At  one 

extreme  1  /2®»»  I  ,  and  at  the  other  extreme  —  as  the  exponent  increases  —  the  value  r»i 

y  approaches  0  .  Thus,  we 

assert  OtySI  in  Pt  . 

The  program  contains  two  assignments  to  the  variable  t , 
z:«0  z:*z+y  . 

Since  we  have  already  determined  that  y  Is  always  of  the  form  l/2n  ,  It  follows  that  z 
must  be  a  sum  of  some  finite  number  (possibly  zero)  of  elements  of  that  form.  This  does 
not  tell  too  much  about  t ;  it  does,  though,  give  the  lower  bound 

assert  z20  in  Pt  , 


since  y  is  always  positive. 


►*  » 
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The  loop  terminates  when  the  exit  test  yU  becomes  true.  Thus,  whenever  control 
reaches  the  label  £, ,  the  relation  ySt  must  hold.  This  is  expressed  by  the  local  invariant 

£,:  assert  yit  . 

Similarly,  if  the  exit  test  is  not  taken  and  the  loop  body  Is  executed,  then  the  exit  test 
must  have  been  false,  i.e.  y>t . 

Neither  branch  of  the  conditional  statement  affects  y  ,  and  therefore  the  relation  y>e 
holds  after  the  conditional  statement  as  well.  At  that  point  y  is  divided  by  2  .  If  before 
the  division  we  had  y>e  ,  then  at  the  end  of  the  loop  body  we  have  2-y>e  .  So,  whenever 
the  loop  body  is  executed  control  returns  to  the  head  of  the  loop  with  the  relation  2 -y>e 
holding.  Since  that  relation  does  not  necessarily  hold  when  the  loop  is  first  entered  with 
y~\  ,  It  is  not  a  loop  invariant.  Nevertheless,  the  disjunction  of  the  relations  y«l  and 
2*?><  is  a  loop  invariant,  since  one  relation  holds  when  the  loop  is  first  entered  and  the 
other  holds  every  time  the  loop  is  repeated,  I.e.  we  have 

Lf:  assert  y*  I  V2*}><  . 

Consider  the  conditional  statement 

if  d'(z+y)ic  then  z  :■  z*y  ti  . 

It  is  an  abbreviation  of  the  statement 

if  d'(z+y)se  then  z  :■  z*y  else  fi 

which  has  an  empty  else-branch.  The  then-path  of  the  conditional  statement  is  taken 
when  d»[z+y)<c  ;  therefore,  after  resetting  z  to  z*y  we  have  d-zic  .  Since  the 
programmer  introduced  the  conditional  statement  to  achieve  some  specific  relation  in 
different  cases,  it  is  plausible  that  the  relation  d*z Se  —  achieved  by  the  then-path  of  the 
conditional  —  is  the  intended  relation  and  holds  for  the  elae-path  as  wed.  This  suggests 
the  candidate 

L(:  suffast  d> zSe  . 

Indeed,  since  d'Zic  Is  true  Initially,  when  z»0  and  ciO ,  and  ie  unaffected  when  the 
conditional  test  Is  false  (since  the  value  of  z  Is  not  changed),  It  invariently  holds  when 
control  reaches  the  head  of  the  loop.  We  have  derived  the  loop  Invariant: 

L,:  assert  d*zSc  . 

The  then-peth  Is  not  taken  when  e<d>(z*y) .  In  that  ease  y  Is  divided  In  half  and  z 
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Is  l«ft  unchanged,  yielding  c<d*(z+2*j)  at  the  end  of  the  current  Iteration.  It  turns  out 
that  the  then-path  preserves  this  relation  and  that  It  also  holds  upon  initialization.  Thus 
we  have  the  additional  invariant: 

L,:  assert  c<<f*(z+2*j)  . 

The  loop  invariants  d-zic  and  c<d>(z+ 2*y)  remain  true  when  the  loop  exited  is  taken; 
along  with  the  exit  test  yit ,  they  Imply  that  upon  termination  of  the  program  the  output 
Invariant 

£,:  assert  |r/d-z|<2*< 

holds.  Note  that  the  desired  relation  |c/rf-z|<«  is  not  Implied. 

The  annotated  program  —  with  invariants  that  correctly  express  what  the  program 
does  —  is: 

I - - - 1 

|  assert  0£e<rf,  <>0,  j€l/2N.  z*0  in  | 

|  Pt:  begin  comment  annotated  bad  division  program  | 

I  £,:  assert  0 Sc<d,  t> 0  | 

I  <*.j)  (0,1)  j 

|  loop  Lt:  assert  d*zSe,  c<d’{z*2*y),  y-lV2*y>*  | 

j  suggest  d»zSe,  c<d-(z*y)  j 

j  until  yS*  | 

j  t  if  d'(z+y)Sc  then  z  :■  z*y  fi  j 

I  y  :•  y/2  | 

j  repeat  j 

j  £,:  assert  |c/d-z|<2*r  | 

j  suggest  |c/d-z|<*  j 

j  end  .  | 

I  -  —  _ l 


We  have  omitted  the  purpose  statements  to  avoid  clutter. 
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3.  Debugging 

Now  that  we  know  something  about  what  the  program  does,  we  can  try  to  debug  it. 
Our  task  is  to  find  a  correction  that  transforms  the  actual  output  Invariant 

assert  |e/rf-z|<2’< 

into  the  desired  output  candidate 

suggest  |c/d*z|<<  . 

We  shall  then  apply  that  transformation  to  the  program  in  an  attempt  to  derive  a  correct 
program. 

Accordingly,  we  would  like  to  modify  the  program  In  such  a  manner  as  to  transform  the 
insufficient  |c/rf-z|<2*f  into  the  desired  |c/rf-z|<«  ;  we  write 

|c/d-z|<2*«  =>  |c/d-z|<«  . 

The  obvious  difference  between  the  two  expressions,  is  that  where  the  first  has  2*r  .  the 
second  has  just  e  .  So,  to  transform  |c/d-*l<2**  into  |c/«f-z|<«  ,  we  need  only  transform 

2*r  **  e  , 

leaving  the  other  symbols  unchanged.  This  may  be  accomplished  by  replacing  e  with  e/2  , 
i.e.  by  applying  the  transformation  e  e/2  .  In  this  manner,  we  get 

|c/rf-z|<2*«  =*  |c/rf-z|<2-«/2  s  |c/d-z|<r  . 

We  see  that  the  transformation  t  **  t/2  ,  applied  to  the  output  invariant  |c/d-z|<2*r  , 
yields  the  desired  output  specification  \:/i-t\<.t .  That  same  transformation  is  now  applied 
to  the  whole  annotated  program  (excluding  the  programmer's  suggestions).  The  symbol  t 
appears  once  in  the  program  text:  the  exit  clause 

until  y<e 

accordingly  becomes 

until  yie/2  . 

The  symbol  also  appears  four  times  in  the  Invariants;  for  example,  the  input  assertion  eX) 
transforms  into  e/2>0  which  is  equivalent  to  *X> . 


The  transformed  program  is 
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I - 1 

|  uwrt  0 ic<d,  *> 0,  y«l/2N,  ziO  in  | 

j  Pt:  begin  comment  corrected  division  program  | 

|  Bt:  assart  0 Sc<d,  tX)  | 

|  (z,y)  (0. 1)  j 

j  loop  Lt:  uurt  d'Zic,  c<d‘(z*2*y),  ylV4j>i  j 

|  suggest  d-zSc,  c<d‘(z*y)  | 

j  until  y<e/2  j 

]  if  d-(z+y)<c  then  z  :■  z*J  fi  j 

I  y  :•  y/2  | 

j  repeat  j 

j  £.:  assert  | c/d~z\<e  j 

|  surest  \c/d~z\U  | 

j  end  .  | 

l _ l 

In  an  appendix,  it  is  proved  a  transformation  such  as  e  •*  e/2  preserves  the  relation 
between  the  program  text  and  Invariants,  i.e.  the  transformed  assertions  are  invariants  of 
the  transformed  program. 

In  this  manner,  we  have  modified  the  program  to  achieve  the  intended  result  |c/rf-r|<e  . 
But  note  that  the  loop  invariant  still  differs  from  that  suggested  by  the  programmer.  The 
difference  between  the  two  is  that  the  programmer  intended  for  c<d-(z*y)  to  be  true, 
while  in  fact  c<rf*(z*2*j)  holds.  This  can  be  remedied  by  applying  the  transformation 

y*y/2  . 

The  variable  y  appears  five  times  in  the  program  code:  The  exit  clause  becomes 
until  y/2$e/2  , 
or  equivalently 

until  y<t  . 

The  conditional  statement  becomes 

if  d‘(x+y/2)ie  then  z  :•  t+y/ 2  fi  . 

The  assignment  statement 
y  i 
transforms  into 


yn  >  1  . 


which,  however,  Is  not  a  legal  assignment,  aince  an  expression  appears  on  the  left-hand 
aide.  The  Intent  of  this  Illegal  statement  Is  to 

achieve  y/2-1  varying  y  . 

By  multiplying  the  two  sides  of  the  equality  by  2  ,  It  Is  seen  to  be  equivalent  to 
achieve  y=2  varying  y  , 
which  may  be  accomplished  by  the  assignment 

y  2  . 

Similarly,  the  original  assignment 
y  :=  y/2 


gives  rise  to  the  goal 

achieve  y/2  *  (// 2)/2  varying  y  , 


where  y '  represents  the  prior  value  of  the  variable  y  .  Again,  by  multiplying  both  sides  by 
2  ,  we  derive  the  assignment 

y  :■  y/2  . 

Thus,  we  have  obtained  the  program: 

r 

1 

assert  0 *c<d,  eX),  jc1/2W,  ziO  in 

1 

1 

Ptf:  begin  comment  transformtd  division  program 

1 

assert  0 Se<d,  t  X) 

1 

1 

(z,y)  (0,2) 

1 

1 

loop  Lt:  assert  d-iic,  e<d>(z*y),  j»2V2*j>< 

1 

1 

suggest  d’Zic,  c<d‘{z*y) 

1 

1 

until  y<* 

1 

1 

if  d'(z+y!2)Sc  than  *  :«  t*y/ 2  fi 

1 

1 

y  y/2 

1 

I 

repeat 

1 

1 

£t:  assert  |e/rf-z|<* 

1 

1 

suggest  |e/d-r|<« 

1 

1 

1 

end  . 

1 

I 
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Since  the  expression  y/2  appears  thrice  in  the  loop  body,  this  program  may  be 
slightly  improved  by  evaluating  the  subexpression  y/2  before  the  conditional  statement. 
We  obtain: 


I - 1 

|  assert  0 ic<d,  <X),  ycl/2M,  zfcO  In  | 

|  P"\  begin  comment  good  division  program  j 

|  Bt:  assert  0 $c<d,  rX>  | 

|  (z.y)  (0,2)  j 

|  loop  Lt:  assert  d*tU,  e<d»(t*y),  y*2V2y>e  | 

j  until  yU  j 

I  y  yn  | 

j  if  d-U+y)Zc  then  z  :»  t+y  fi  | 

j  repeat  | 

j  £,:  assert  |c/<f-z|<<  j 

j  end  .  | 

I _ I 

Note  that  this  program  is  almost  the  same  as  the  original  bad  program.  It  differs  in  two 
ways:  the  two  loop-body  assignments  are  interchanged  (this  presumably  was  the  error), 
and  y  Is  Initialized  to  2  rather  than  1  (either  initialization  works). 


4.  Modification 

Consider  the  following  specifications: 

- , 

P, :  begin,  comment  squart-rooi  program  | 

assert  a2l,  t> 0  | 

achieve  |V<f-z|<<  varying  z  | 

end  .  I 


We  would  (Ike  to  use  the  corrected  real-division  program  as  a  basis  for  the  construction  of 
the  specified  program  for  computing  square-roots.  We  assume  that  the  ■/”  operator  Is 
not  primitive. 

To  this  end,  we  first  compars  the  specifications  of  the  two  programs.  The  output 
specification  of  the  division  program  is 

assert  |c/d-z|<« 

while  the  output  specification  of  the  desired  program  is 
achieve  |V«-z|<#  varying  z  . 
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The  obvious  analogy  between  the  two  la 

c/d  «*■  Va  , 

i.e.  where  one  has  c/d  ,  the  other  has  Va .  Thus,  to  obtain  a  square-root  program  from 
the  division  program,  we  need  to  transform  c/d  into  -/a  .  One  way  to  do  this  would  be  via 
the  transformations 

(rf  =>  1 .  c  =»  V 5)  , 

which  take  c/d  into  Va/l  -Va  .  Here  d  is  transformed  into  the  identity  element  of  the 
division  operator,  leaving  c  to  become  Va .  Alternatively,  we  could  apply  the 
transformation 

( u/v  =>  Vu,  c=>«) 

where  by  u/v  =>  Vu  we  mean  that  every  occurrence  of  the  division  operator  is  replaced 
by  the  square-root  operator  applied  to  what  was  the  numerator. 

We  apply  the  first  set  of  transformations  to  the  division  program  P. ,  annotated  with 
only  those  invariants  essential  for  proving  correctness.  Replacing  all  occurrences  of  d 
with  1  and  all  occurrences  of  c  with  Va  and  simplifying,  yields 

I - 1 

|  assert  0<Va<l,  <>0  in  j 

|  Py  begin  comment  square-root  program  | 

j  B, :  assert  0<Va<l,  r>0  | 

|  ( z,y )  :=  (0.2)  j 

j  loop  L,:  assert  z£Va,  Va<z*y  I 

|  until  yie  | 

I  y  >/2  i 

|  if  z+y£Va  then  z  :*  z+y  fi  I 

|  repeat  | 

|  £,:  assert  |Va-z|<e  j 

|  end  .  j 

L _ l 

The  transformed  program  Is  guaranteed  to  satisfy  the  output  specification  \Va-2\<e  ; 

unfortunately,  it  is  Inexecutable  inasmuch  as  it  contains  the  nonprimitive  function  V*  in 
the  conditional  test. 

It  is  assumed  that  knowledge  about  the  subject  domain  is  available.  For  example,  we 
need  the  following  fact  about  the  square-root  function: 

fact  usVv  m  u^&v  when  ufeO  , 
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where  u  and  v  are  universally  quantified,  l.e. 

(Vm.v)  (u£0  z>  uiVvmu^iv)  . 

This  fact  allows  us  to  replace  the  test  z*ySVa  with  the  equivalent  (z+j)^£c  .  That  z*y 
la  Indeed  nonnegative,  as  required  for  the  two  tests  to  be  equivalent,  follows  from  the  loop 
Invariant 

L,:  assart  Sa<z*y 

and  the 

fact  0 <.>/u  . 

There  remains  an  additional  problem:  a  transformed  program  is  only  guaranteed  to 
satisfy  the  output  specification  for  those  inputs  that  satisfy  the  transformed  input 
specification.  Unfortunately,  the  transformed  Input  specification  of  our  program, 

assert  OiVai  I ,  r>0  , 

is  contrary  to  the  given  input  specification  a&l  .  To  solve  this,  we  can  replace  the  code 
preceding  the  loop  with  the  goal 

assert  a2l,  <>0 

achieve  ziVa,  Va<z+y  varying  z,y  . 

to  initialize  the  loop  invariants  zSVa  and  Va<x+y  prior  to  entering  the  loop.  Achieving 
z^Sa  is  equivalent  to  achieving  z$Va  .  And  since  it  is  given  that  l<a  ,  we  need  only 
achieve  z^z- 1  .  To  achieve  the  second  conjunct  Ja<x+y  ,  given  the 

fact  Vusu  when  u2l  , 

we  need  only  achieve  z+y*  1  *y°a  .  Thus  we  have  reduced  the  goal  to 
achieve  z«i,  l+y*a  varying  x.y  , 
giving  rise  to  the  assignment 
U.y)  :*  (l,«-l)  . 


The  square-root  program  that  we  have  obtained  is: 
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assert  ail,  e>0  in 
/>,:  begin  comment  square -root  program 
Bf:  assert  ail,  e>0 
( z,y )  :=  (l.o-l) 
loop  L,:  assert  z£Va,  Va<z*y 
until  y<e 
y  :=  y/2 

if  (z+yfi<a  then  z  :*  z*y  fi 

repeat 

E  :  assert  |Va-z|<« 


Note  that  the  global  invariant  OsVoO  no  longer  holds. 

The  alternative  set  of  transformations  for  transforming  the  division  program  into  a 
square-root  program  was 

(u/v  =>  >/u,  e  =>  a)  . 

Transformations  that  Involve  specific  functions  such  as  u/v  ,  are  not,  however, 
guaranteed  to  yield  a  correct  program,  since  the  program  may  be  based  on  some  property 
that  holds  for  u/v  but  not  for  Vu  .  These  transformations  are  heuristic  In  nature;  they 
only  suggest  a  possibly  incomplete  analogy  between  the  two  programs.  Indeed,  when 
applied  to  the  division  program,  the  transformations  yield 


suggest  0 £a<d,  e>0  in 

P’\  begin  comment  transformed  division  program 
suggest  0 Said,  e>0 
(z,y)  :*  (0,2) 

loop  L'\  suggest  d'zia,  o<d*( z*y) 
until  yie 

y  >  Jy 

if  d'(z+y)<,a  then  z  :■  z*y  fi 

repeat 

suggest  \-/a-z\<e 
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which  clearly  does  not  compute  Va.  Since  this  set  of  transformations  is  not 
correctness-preserving,  the  asserted  invariants  have  been  replaced  by  suggested 
candidates. 

What  must  be  done  is  to  review  the  derivation  of  the  program,  expressed  in  the 
purpose  statements  and  see  where  the  analogy  breaks  down.  The  purpose  of  the  division 
program  is  j c/d-z\<e  which  transforms  into  |vSF-z|<#  as  desired.  The  programmer  achieved 
|c/rf-z|<<  by  breaking  it  into  the  conjunction  of  three  subgoals,  given  in  the  statement 

purpose  c/diz,  c/d<z*y,  yit 

that  appeared  in  the  original  program.  The  last  conjunct  became  the  exit  test,  and  the 
other  two  became  loop  invariants.  These  subgoals  transform  into 

purpose  >/5>z,  >/a<z*y,  y<t  , 

which  indeed  imply  the  transformed  goal  |v^s-z|<r  . 

The  purpose  of  the  loop  body  of  the  division  program  (though  it  was  left  out  of  P,  ) 

was 


purpose  c/diz,  c/d<z*y,  0<y<yL  , 

where  yL *  represents  the  value  of  the  variable  y  when  last  at  the  head  of  the  loop,  at 

label  Lt .  In  other  words,  the  loop  body  reachieves  the  invariants  while  making  progress 
towards  the  exit  test  by  decreasing  y  (to  guarantee  termination,  that  decrease  cannot 
be  arbitrarily  small).  The  loop-body  subgoal  of  the  transformed  program,  then,  is 

purpose  VSiz,  Va<z*y,  0<y<yL ,  . 

The  division  program  first  decreases  y  and  then  introduces  a  conditional  with  the 
purpose  c/diz,  c/d<z*y  . 

It  is  here  that  the  analogy  breaks  down.  The  loop  body  of  the  division  program  achieves 
this  purpose  In  two  cases,  by  testing  if  d>{t*y)ic  or  not.  For  example,  if  d-(z*y)<c  does 
not  hold,  then  c/d<z+y  ,  as  desired.  On  the  other  hand,  the  fact  that  d»(z*y)<a  does  not 
hold  in  the  square-root  program  tells  nothing  about  Va<z*y .  We  look,  therefore,  for  a 
transformation  that  will  allow  the  implication 

d’(z*y)>a  o  Jo<z*y 

to  hold.  As  for  the  previous  alternative,  since  z*y  is  nonnegative,  the  right  hand  side  of 
the  implication  Is  equivalent  to  a<(z*y)% .  Matching  the  left-hand  side  of  the  implication 


22 


■4 


with  this  inequality,  tells  us  that  the  Implication  would  hold  if  we  could  transform 
d’(z*y)  =>  (z*y)2  .  Thus,  where  the  division  program  has  the  function  trv  ,  the  square-root 

program  requires  .  We  complete  the  analogy  by  adding  the  transformation  u» v  =»  i/2  , 
to  obtain 


(u/w  *>  Vu,  c  a,  U'V  =*  v%)  . 

Finally,  as  with  the  first  set  of  transformations,  the  initialization  subgoal  does  not  hold, 
and  must  be  replaced  by  the  assignment 


( z,y )  :*  (l,«-l)  • 

The  same  program 

r - 1 

|  assert  t^i,  <>0  in  j 

|  P,:  begin  comment  square-root  program  j 

|  B,:  assert  a>l,  «>0  | 

|  (z,>)  :=  (l,a-l)  j 

|  loop  L,:  assert  ziVa,  Va<z*y  | 

j  until  ><e  | 

I  y  :=  [ 

j  if  (z+yfi<a  then  z  :*  z*y  fi  | 

|  repeat  | 

|  £,:  assert  |Va-z|<r  | 

|  end  | 

I _ I 

Is  obtained. 


5.  Abstraction 

We  now  have  two  programs,  P8  tor  finding  the  quotient  and  P,  for  finding  the 
square-root.  Both  programs  utilize  the  binary-search  technique.  We  would  like  to  extract 
an  abstract  version  of  the  two  programs  that  captures  the  essence  of  the  technique,  but 
that  is  not  specific  to  either  problem.  The  resultant  abstract  program  schema  can  then  be 
used  as  a  model  of  binary  search  for  the  solution  of  future  problems. 

Consider  the  second  analogy  that  we  found  between  Pt  and  P, : 

( u/v  «♦  Vu,  c  ♦*  «,  U'V  i>2)  . 
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Both  u/v  and  Vu  are  functions;  they  may  be  generalized  to  some  abstract  function 

f(u,  v)  .  Similarly  the  generalization  of  u*e  and  rfi  Is  g(u,  v) .  Since  both  e  and  e  are 
variables,  we  can  leave  them  as  Is.  This  gives  us  the  following  set  of  transformations  to 
generalize  the  division  program: 

(u/v  «*/(u, v).  u-v  +  g(u, »))  . 

Applying  these  transformations  to  the  specifications 
achieve  \c/d-z\<e  varying  z 
of  the  division  program  yields 

achieve  \f(c,  rf)-r|<<  varying  z  . 

This,  then,  shall  be  the  abstract  output  specification  of  the  schema.  The  division  program 
was 


1 — 

1 

begin  comznent  good  division  program 

Bt :  assert  Quid,  eX> 

(z.y)  (0.2) 

loop  L{:  assert  <f«zSc,  c<d-(z*y) 

until  yie 

y  :«  y/2 

if  d-(z*y)U  then  z  :•  t+y  fl 

repeat 

Et :  assert  |c/d-z|<« 

i _ 

end  . 

-j 

Substituting  the  abstract  predicates  /  and  g  into  their  respective  positions  in  the 
annotated  program,  we  derive  the  schema: 


|  Pt:  begin  comznent  transformed  division  program 
|  Bt:  assert  0Se<rf,  #>0 

j  (z.y)  (0,2) 

j  loop  L}:  assert  g(d,z)Se,  e<g(d,t*y ) 

|  until  yit 

I  y  •*  yn 

j  if  g(d,  z+y)$c  then  z  >  z*y  ti 

j  repeat 

j  Et:  assert  |f(c,d)-z|<« 

|  end  . 

i _ i 
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This  schema  is  not  necessarily  correct  for  all  instantiations  of  /  and  g  ,  as  the 
original  program  relied  upon  facts  specific  to  /  and  Indeed,  there  is  nothing  in  this 
abstract  program  to  relate  the  function  /  that  appears  in  the  output  specification  with 
the  function  g  that  appears  In  the  loop  Invariant.  In  general,  transformations 
(abstractions)  of  specific  function  or  predicates  are  not  correctness-preserving.  We 
would  like  then  to  determine  under  what  conditions  this  abstract  schema  does  achieve  its 
specifications. 

As  in  the  modification  step,  the  initialization  assignment  does  not  necessarily  achieve 
the  desired  loop  invariants.  We  therefore  replace  the  initialization  assignment  with  the 
subgoal 

achieve  g(d,z)$c,  c<g(d,  z+y)  varying  z,y  , 
leaveing  unspecified  how  to  initialize  the  two  loop  invariants. 

For  the  loop-body  path  to  be  correct,  the  truth  of  the  invariant  must  imply  that  the 
invariant  will  hold  the  next  time  around;  this  can  easily  be  shown  to  be  the  case  for  any 
function  g  .  For  the  loop-exit  path  to  be  correct,  we  must  have  that  the  loop  invariants 
g(d,  z)<c  and  c<g{d ,  z*y)  plus  the  exit  test  yie  imply  that  the  output  invariant 
\f(c,d)-z\<e  holds.  For  this  to  be  the  case,  it  suffices  to  establish  the  condition 

assert  g(u,uHv  s  u£f(v,w)  . 

This  assertion  holds  if  g  is  the  inverse  of  a  monotonic  function  /,  i.e.  figW.  u),  w)-u 
and  (u£v)s{f(u,w)*f(v,w) ,  as,  for  example,  ♦  is  the  Inverse  of  /  and  is  the  inverse 
of  Vu  . 

In  this  manner,  we  have  derived  a  general  program  schema  for  a  binary  search  for  the 
value  of  /(c,<f)  within  a  tolerance  <: 


1 - 

1 

begin  comment  binary-search  schema 

“1 

0/  assert  g(w,u)Sv  a  u<,/(v,u) 

achieve  g(z,d)Sc,  c<g(z*y,d)  varying  z,y 

loop  Lt:  assert  g(d,  z )&,  c<g(d,  z*y) 

until  yie 

y  :«  y/2 

if  g{d,z*y)Sc  then  z  :«  z*y  fi 

repeat 

£4:  assert  |/'(«,<f)-z|<< 

end  . 

1 _ 

_J 

Its  output  specification  is 


'm;  urw 
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uurt  | f(c,  d)-z\Zt  , 

and  Its  precondition  for  guaranteed  correctness  Is 
assert  g(w,u)iv  a  u4f(v,  w)  . 

Clearly,  the  function  g  which  appears  in  the  schema  must  be  primitive;  otherwise,  it  must 
be  replaced  by  something  equivalent  for  the  schema  to  yield  an  executable  program.  The 
unachieved  subgoal 

achieve  g(z,d)$c,  c<g(z*y,d)  varying  z,y 
must  also  be  reduced  to  primitives. 


6.  Instantiation 

We  Illustrate  how  the  binary-search  schema  just  derived  may  be  applied  to  the 
computation  of  Integer  square-roots.  Our  goal  is  to  construct  a  program  that  finds  the 
integer  square-root  z  of  a  nonnegative  integer  a  : 

i  - 1 

(  Pt:  begin  comment  integer  square-root  program  | 

|  Bf\  assert  aeN  | 

|  achieve  z=[VaJ  varying  z  | 

|  and  .  | 

«  1 

where  the  function  |u J  yields  the  greatest  integer  less  than  or  equal  to  u  . 

We  cannot  directly  match  this  goal  with  the  output  specification  of  the  schema 
assert  ^(c,d)-z\<t  varying  z  , 

or  with  any  of  the  other  Invariants  known  to  hold  upon  termination  of  the  schema. 
However,  If  we  expand  the  goal  za[Vaj  ,  using  the  definition  of  [uj  , 

fact  v>Luj  a  viuAu<v*lAveZ 

(where  Z  is  the  set  of  all  Integers),  we  get  the  equivalent  goal 

achieve  zsVa,  Va<z+1,  zcZ  varying  z  , 

l.e.  z  should  be  the  largest  Integer  not  greater  than  Va  .  Since  we  know  that  the  schema 
achieves  the  two  output  invariants 

assert  zsf(c,d),  f(c,dXz*t  , 
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we  compare  these  Invariants  with  the  above  goal.  This  suggests  the  transformation 
(f(u,v)  ^  Vu.c  -a  e,«  -a  I) 

to  achieve  the  two  conjuncts  ziVa  and  Va<z+1  ;  In  addition,  we  will  have  to  extend  the 
program  to  ensure  that  the  final  value  of  z  is  a  nonnegative  integer.  For  this  purpose,  we 
append  the  subgoal 

achieve  zeZ  protecting  ziVa,  Va<z*  I  varying  z 

to  the  end  of  the  instantiated  schema.  The  protecting  clause  means  that  the  relations 
ziVa  and  Va<z+1  ,  achieved  by  the  loop,  may  not  be  clobbered  when  achieving  the 
additional  goal  zel . 

The  precondition  for  the  schema's  correctness  is 
assert  g(u>,u)io  s  u<f(v,w)  ; 
instantiating  it  yields 

assert  g(tv,u)<v  s  u^Vv  . 

Recalling  that 

fact  uiVv  s  u?<v  when  uiO  , 

this  condition  may  be  satisfied  by  taking  g(u/,  u )  to  be  u?  ,  provided  that  the  argument 
u  is  never  negative.  This  completes  the  analogy,  obtaining  the  transformations 

(f(u,v)  =»  Vu.c  =*  a,t  **  l,;(w,u)  «^)  . 

Applying  this  instantiation  to  the  schema,  we  obtain  the  partially  written  program: 


1 - 

1  Pr 

begin  comment  integtr  squart-root  program 

~ 1 

Bh:  assert  aeN 

achieve  z<Va,  Ja(z*y  varying  z,y 

loop  assert  zl-/a,  Va<z*y 

until  yi  1 

y  y/2 

if  (z+yj*£a  then  z  :■  z*y  ft 

repeat 

assert  ziVa,  Ja<z+ 1 

achieve  zeZ  protecting  ziVa,  Va<z*  1  varying  z 

l _ 

end  . 

_J 

That  the  argument  z*y  is  nonnegative  follows  from  the  invariant  Va<z*y  . 


GENERAL  OVERVIEW 


Z7 


1.  Synthesis 

This  program  still  contains  two  una chieved  subgoals: 
achiav*  ziVa,  Va<z*y  varying  z,y 

and 


achiava  zeZ  protecting  zSVa,  Va<z+I  varying  t  . 

We  show  now  how  these  subgoals  may  be  achieved. 

The  first  subgoal  Is  a  conjunction  of  two  relations,  ziVa  and  Va<z*y  ,  which  are  to 
be  achieved  simultaneously.  It  may  be  split  into  the  two  consecutive  subgoals 

purpose  ziVa,  Va<z*y 

achieve  ziVa  varying  z 
achiava  Va<z*y  varying  y 
assert  ziVa,  Va<* *y  . 

The  first  sets  the  variable  z  to  some  value  satisfying  ziVa  ;  the  second  leaves  t 
constant  so  that  ziVa  remains  true,  and  sets  y  to  some  value  satisfying  Va<z*y  .  We 
can  solve  the  first  by  setting 
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since  x  remains  0  while  achieving  the  next  subgoal  Va<z*y  ,  that  subgoal  becomes 
achieve  Va<y  varying  y  . 

We  shall  return  to  this  subgoal  later.  Of  course,  there  is  no  assurance,  as  yet,  that  this 
split  will  lead  to  a  satisfactory  solution;  were  It  not  to  work  out  in  the  end,  then  we  would 
have  to  retrace  our  steps  to  this  point  and  try  something  else. 

There  are  two  ways  In  which  we  might  achieve  the  other  remaining  subgoal 

achieve  zeZ  protecting  zsVa,  Va<z*  I  varying  z  . 

One  is  to  take  the  current  value  of  z  which  satisfies  the  two  conditions  z<Va  anck 
Va<z*l  and  perturb  it  just  enough  to  make  it  an  integer  while  preserving  those  two 
protected  relations.  This  can  be  done  by  assigning 

z  :«  [zj  . 

Alternatively,  we  note  that  the  above  subgoal  Is  equivalent  to 

achieve  zcM  protecting  ziVa,  Va<z*  I  varying  z 

since  zeZ  and  Va<z+1  imply  that  z  is  nonnegative.  To  achieve  this,  we  set  up  the  new 
goal 

achieve  zeM  in  Pf  , 

by  which  we  mean  that  zcM  Is  to  be  a  global  Invariant  of  Pf .  Accordingly,  we  must 
establish  zcN  initially  and  then  preserve  It  throughout  the  loop  computation.  Initially 
z*0eM  ,  as  Is  desired.  Since  z  is  sometimes  incremented  by  y  ,  the  latter  should  also  be 
a  nonnegative  integer.  That  gives  us  a  new  goal 

achieve  jeW  in  Py  . 

Finally,  In  order  to  preserve  the  Invariant  ?eN  ,  while  It  is  repeatedly  halved  until  it  is 

no  longer  greater  than  1  ,  it  is  necessary  and  sufficient  that  be  Invariant.  Thus,  we 
have  the  stronger  goal 

achieve  in  Pt  . 

For  ?«2m  to  hold  throughout,  we  need  to  ensure  that  It  holds  upon  entering  the  loop. 
Accordingly,  we  add  the  conjunct  ?c2^  to  the  Initialization  subgoal  Va<y  . 

We  are  left  with  the  unachieved  subgoal 

achieve  v/a<t.  ve2M  varying  y  . 


»•>  * 


.  .tvj^-«**ti",  ^v-^vi 


GENERAL  OVERVIEW 


29 


The  first  conjunct  might  be  achieved  by  letting  y»a*\  ,  white  the  second  could  easily  be 
achieved  by  letting  y*l  .  However,  though  each  conjunct  is  achievable  by  itself  in  this 
manner,  achieving  both  together  Is  more  difficult,  since  in  general  these  two  solutions 
conflict  with  each  other.  So,  instead,  we  transform  this  conjunctive  goal  into  an  iterative 

loop,  choosing  first  to  achieve  ?c2w ,  and  then  to  keep  It  true  while  executing  the  loop 
until  the  remaining  conjunct,  Va<y  ,  is  also  satisfied.  Since  is  not  a  primitive  function, 
we  must  test  for  the  equivalent  a<y*  : 

purpose  Va<y,  ye2^ 

achieve  jc2w  varying  y 
loop  L(:  assert 
until  a<y% 

approach  a<y^  protecting  yc2^ 
repeat 

assert  Va<y,  >e2N  . 


To  initialize  ?c2M  ,  we  let  y* 2®  and  assign 

y  >  » 

Within  the  loop,  we  have  the  subgoal 

approach  a<y%  protecting  yc2w  , 

i.e.  we  wish  to  preserve  the  Invariant  jc2^  while  making  progress  towards  the  exit  test 

a<j2  .  since  we  know  that  initially  y=  I  ,  and  ultimately  we  want  Oi-/a<y  ,  it  follows  that 
y  Is  increasing.  Assuming  that  y  is  to  Increase  monotonically,  we  get  the  loop-body 
subgoal 

achieve  y>yL  protecting  ;e2M  . 

where  yL  is  the  value  of  y  when  control  was  last  at  L,  .  It  follows  that  y  must  be 
multiplied  by  some  positive  power  of  2  ,  e.g. 


y  :■  2*?  . 
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We  have  obtained  the  following  program: 

assert  aeN,  zeN,  j«2n  in 
Pt:  begin  comment  Integer  square -root  program 
Bt:  assert  «cM 
purpose  zi'/a,  Va<z*y 
z  :=  0 

y  >  I 

loop  Lt:  assart 
until  a<y% 
y  :=  2*31 

repeat 

loop  Lf:  assert  ziVa,  Va<z*y 
«  |  until  jSl 

|  y  >  >/2 

|  if  (z+yfea  then  z  >  z+y  ti 

|  repast 

j  £,:  assert  z5SVa,  Va<z*l,  zcN 

|  end  . 

This  program  can  be  improved  as  will  be  illustrated  in  the  chapter  on  synthesis. 


1.  INTRODUCTION 


Program  modification  has  as  its  goal  the  transformation  of  a  given  program  into  a  new 
program  to  achieve  a  different  goal.  We  have  already  seen  how  a  program  that  divides  is 
modified  to  compute  square-roots.  The  essence  of  our  approach  Is  to  find  an  analogy 
between  the  specifications  of  the  given  program  and  those  of  the  program  that  we  desire 
to  construct.  This  analogy  Is  then  used  as  the  basis  for  transforming  the  existing  program 
to  meet  the  new  specifications.  Invariant  assertions  play  an  important  role  in  this  process. 
Program  debugging  Is  considered  as  a  special  case  of  modification:  If  a  program  computes 
wrong  results,  It  must  be  modified  to  achieve  the  Intended  results. 

The  use  of  analogy  In  problem  solving  in  general,  and  theorem  proving  In  particular,  is 
discussed  by  Kllng  [1071].  Other  works  employing  analogy  are  Brown  [1976]  and  Chen 
and  Flndler  [1076].  The  modification  of  an  already  existing  program  to  solve  a  somewhat 
different  task  was  suggested  by  Manna  and  Waldinger  [1976]  as  part  of  a 
program-synthesis  system.  Also,  the  STRIPS  (Fikes,  Hart  and  Nilsson  [1072])  and  HACKER 
(Sussman  [1076])  systems  were  to  some  extent  capable  of  generalizing  and  reusing  the 
robot  plans  they  generated.  Recently,  Ulrich  and  Moil  [1977]  have  been  investigating  the 
role  of  analogy  in  program  synthesis.  Katz  and  Manna  [Apr.  1076]  and  Sagiv  [1076] 
discuss  debugging  techniques  based  on  invariant  assertions;  Boyer,  Elspas,  and  Levitt 
[1076]  and  King  [1976]  describe  debugging  aids  based  on  the  symbolic  execution  of  a 
program. 

The  next  section  elucidates  the  basic  aspects  of  our  approach  to  program 
modification  with  the  aid  of  several  relatively  straightforward  examples.  More  subtle 
facets  of  the  techniques  are  illustrated  in  the  examples  of  Section  3.  The  correctness  of 
the  technique  is  discussed  in  an  appendix. 


2.  OVERVIEW 

For  program  modification,  one  is  given  a  known  correct  program  with  its  Input-output 
specification  and  the' specification  for  a  desired  new  program;  comparison  of  the  two 
specifications  suggests  a  transformation  that  is  then  applied  to  the  given  program.  Even  if 
the  transformed  program  does  not  exactly  fulfill  the  specifications,  It  can  serve  as  the 
basis  for  constructing  the  desired  new  program. 
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I .  Basic  T echniqut:  Global  T raruformation 

We  distinguish  between  two  types  of  objects,  constants  and  variables :  a  constant  is  any 
symbol  appearing  In  a  program  with  assumed  properties,  e.g.  0  ,  true  ,  *  ,  and  i  ;  a 
variable  is  any  symbol  appearing  In  the  program  with  no  assumed  properties  other  than 
those  mentioned  in  the  input  specification.  A  variable  that  changes  value  during  program 
execution  is  termed  a  program  variable;  any  other  variable  is  considered  to  be  an  input 
variable.  A  program  variable  appearing  in  the  output  specification  is  called  an  output 
variable. 

In  the  examples  of  program  modification  presented  here,  we  stress  transformations  in 
which  all  occurrences  of  a  particular  symbol  throughout  a  program  are  affected.  Such 
transformations  are  termed  "global",  in  contrast  with  "local"  transformations  that  are 
applied  only  to  a  particular  segment  of  a  program. 

As  a  simple  example,  consider  the  following  annotated  program  (due  to  R.W.  Floyd): 


|  Px:  begin  comment  array-minimum  program  | 

]  assert  n&O  | 

I  J  n  | 

j  loop  assert  min(i4[?:2*j])-min(/f[n:2*n])  ,  0<yin  j 

j  until  j-0  | 

j  if  then  :»  >4[2*?-l]  ] 

j  else  >4|jH]  :«  if[2*j]  j 

j  fi  j 

I  J  :■  I 

j  repeat  j 

|  assert  ^[0]-min(>4[n:2>n])  | 

I  and  .  | 

l  ■  .  .  -  l 

The  symbol  n  appearing  In  the  program  Is  an  Input  variable,  A  Is  sn  output  vsriable,  and 
y  Is  a  program  variable;  the  symbols  0  ,  min  ,  $  ,  etc.  are  constants. 

Given  an  array  segment  A[n:2'n]  that  Is  nonempty  (l.e.  n  is  nonnegative),  when  this 
program  terminates,  j4[0]  will  contain  the  minimum  of  the  values  of  the  n+l  array 
elements  A[n]  ,  A[n*  1  ],...,  A[2*n]  .  This  output  specification  is  formally  expressed  In 
the  final  statement 

assert  /f[0]-mfnM[n:2an})  . 

That  the  program  satisfies  this  specification  may  be  proved  using  the  loop  Invariant 
assert  min(A[y:2'y))"mtn(A[n#ti])  ,  OiySn  . 
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(This  Invariant  holds  initially  when  y*n  ,  Is  maintained  true  by  the  loop  body,  and,  together 
with  the  exit  test  31*0  ,  implies  the  output  specification,  since  mfn(/t[0:2*0])=>f[0]  . 

To  modify  this  program  to  compute  the  maximum  of  the  array,  rather  than  the  minimum, 
we  compare  the  specification  of  the  given  program  Pt , 

assert  ^[0]=minM[n:2*n])  , 
with  the  output  specification  of  the  desired  program  Pt , 

achieve  j4[0]-max(>4[n:2<n])  varying  ^[0:n-l] 

We  say  that  we  are  looking  for  an  analogy 

vf[0]*=min(i4[n:2*n])  **  vf[0]«max(if[n:2*n])  . 

The  obvious  analogy  between  the  two  specifications  is  that  one  has  the  function  min 
where  the  other  has  max  ,  l.e. 

min  **  max  . 

This  analogy  suggests  that  by  replacing  all  occurrences  of  min  in  the  first  program, 
we  may  obtain  the  desired  max  program.  But  the  transformation  min  max  alone  will 
not  work.  The  reason  is  that  certain  properties  of  the  constant  min  were  used  in  the 
construction  of  the  program,  and  those  properties  do  not  hold  for  the  new  function  max  . 
Later  on,  we  shall  see  how  this  problem  is  dealt  with. 

In  the  meantime,  there  is  another  way  to  effect  the  transformation 

yf[0]=min(if[n:2*n])  /f[0]=ma*M[n:2*n])  . 

We  first  eliminate  the  function  max(A)  by  replacing  It  with  the  equivalent  -mtn(-A)  , 

where  -A  is  equal  to  the  array  A  with  each  element  negated,  it  remains  to  transform 

^[0]“min(yf[n:2*n])  ^[0]*-mln(-^[n:2*n])  . 

Since  we  do  not  want  to  transform  the  constant  mfn  ,  we  would  like  the  right-hand  sides 
of  both  equalities  to  begin  with  min  .  Multiplying  both  sides  of  ^[0]*-mtn(->f[n:2*n])  by 
>1  ,  we  are  left  with 

yf[0]*min(^[n:2*n])  -^[0>minM[n:2*n])  . 

Now  the  transformation 
A  +  -A  , 


applied  to  the  output  specification  of  the  given  program,  yields 
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assert  -A[0]cmln(-A[n:2‘n]) 
which  is  equivalent  to  the  desired 

achieve  yf[0]=maxM[n:2*n])  varying 


>t[0:n-l]  . 


Since  A  -A  is  a  transformation  of  the  array  variable  A  ,  and  variables  have  no 
assumed  properties,  we  can  obtain  a  program  guaranteed  to  satisfy  the  transformed 
specifications  by  applying  this  transformation  to  the  program.  (By  applying  the  same 
transformation  to  all  occurrences  of  A  In  the  verification  proof  of  the  original  program,  a 
correctness  proof  for  the  transformed  program  is  obtained.) 

The  variable  A  appears  within  the  program  text  only  in  the  conditional  statement 

if  vf[2*y-l]^[2*j]  then  A\y- 1]  :«  A[2y-I] 
else  :=  >f[2*j] 

fi  . 

Applying  the  transformation  A  =>  -A  to  this  statement  yields 

if  ->4[2.}-l]£-y*[2‘j]  then  ->4|>-1]  :«  -/f[2*>-l] 

else  :« 

fi  . 

The  test  -.d[2*y-l]S-,/f[2*y]  is  equivalent  to  A[2y- 1  ]£/i[2*y] .  But  the  transformed 
assignment  statements  are  "Illegal",  since  a  function,  in  this  case  - A  ,  may  not  appear  on 
the  left-hand  side  of  an  assignment.  The  intent  of  the  illegal  statement, 

-*[y- 1]  :•  -A[2'y-\1  . 

however,  Is  for  the  new  value  of  the  expression  to  be  made  equal  to  the  old 

value  of  -A[ 2*?-l]  by  changing  the  value  of  the  array  A  .  In  other  words,  we  wish  to 
achieve  the  relation  given  by  the  goal 

achieve  -A[y-\]=-A'[2‘y~\]  varying  /4[0:n-l]  , 

where  A'  denotes  the  value  of  the  array  A  before  this  achieve  statement.  To  obtain  an 
assignment  to  A  ,  we  must  Isolate  the  variable  A  on  one  side  of  the  equality.  We 
therefore  multiply  both  sides  of  the  equality  by  -I  ,  obtaining  the  goal 

achieve  A\y-\]*A'[2'y-\]  varying  /4[0:n-l]  . 

Since  the  variable  A  appears  on  only  one  side  of  the  equality,  and  OS^-lSn  by  virtue  of 


the  invariant  0<y$n  and  the  exit  test  J=0  ,  we  may  achieve  the  desired  relation  between 
the  new  vplue  of  A  and  the  old  by  assigning  to  A  the  value  of  the  expression  on  the 
other  side  of  the  equality; 

A[y- 1]  >  • 

Similarly,  the  transformed  assignment 
-A[y- 1]  :«  -A[2y] 

becomes 

Global  tranformations  are  applied  to  the  invariants  annotating  the  program  as  well  as 
to  the  code.  Thus  the  loop  invariant 

assert  min(A[y:2,y])smin(A[n:2,n])  ,  0 iyin 

becomes 

assert  min(-A[y:2»y])=min{.-A[n:2‘n])  ,  OZyin  , 
or  equivalently 

assert  maxM[y:2*y])*max(>4[n:2*n3)  ,  Oiyin  . 

We  have  derived  the  following  program  to  compute  the  maximum; 

i - : - 1 

|  Pt:  begin  comment  array-maximum  program  \ 

I  y  :=  n  I 

|  loop  assert  max(jf[3K2*jO)smax(/4[n:2,n])  >  | 

|  until  y=0  I 

|  if  ^[2*7-l]^[2*7]  then  >f[>-13  '•*  ^[2*7-13  j 

I  else  A[y- 1]  :■  A[2-y]  | 

j  fi  j 

I  y  >  7»  I 

j  repeat  | 

|  assert  >4[0]>maxM[n:2*n3)  I 

|  end  .  j 

i  i 

Note  that  the  array  -A  no  longer  appears  In  the  program;  only  the  original  A  Is  actually 
used. 


As  we  have  seen,  global  transformations  are  applied  to  all  the  Invariants  as  well  as  to 
the  oode.  In  particular,  a  transformation  that  effects  an  Input  or  output  variable  changes 
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the  output  Invariant  correspondingly.  Thus,  for  program  modification,  one  looks  for  a 
transformation  of  Input  and/or  output  variables  appearing  in  the  output  invariants  that  will 
produce  Invariants  implying  the  desired  output  specification. 


2.  Special  Cast :  Program  Debugging 

We  consider  the  debugging  process  as  an  Important  special  case  of  program 
modification:  a  program  that  computes  wrong  results  must  be  modified  to  compute  the 
desired  (correct)  results.  If  we  know  what  the  "bad"  program  actually  does,  then  we  may 
compare  that  with  the  specifications  of  what  It  should  do,  and  modify  (debug)  the  incorrect 
program  accordingly. 

As  an  example,  consider  a  program  intended  to  compute  the  integer  square-root  z  of 
the  nonnegative  Integer  c  ;  that  is,  c  should  lie  between  the  squares  of  the  integers  z 
and  z*  I  .  The  goal,  then,  Is  to  achieve  the  relation 

achieve  z*<c,  c<(z+l)“\  zcN  , 

where  N  is  the  set  of  nonnegative  integers,  and  the  given  program  is 


|  Ps:  begin  comment  integer  square-root  program  | 

j  (z,i,  t)  (1,0,3)  j 

|  loop  until  c<s  j 

j  :»  (z*1,j*M»2)  j 

|  repeat  | 

|  end  .  | 

t  I 


Using  the  methods  described  In  the  chapter  on  annotation,  invariants  may  be 
generated  that  express  what  relations  this  program  achieves.  It  turns  out  that  the  global 
Invariants 

assert  /«2*z+l,  j-z^-l,  zcN+l  , 

where  N+l  is  the  set  of  positive  Integers,  hold  throughout  the  program.  Furthermore  the 
loop  Invariant 

assert  cis-t 

holds  whenever  control  is  at  the  head  of  the  loop.  Upon  termination,  the  global  Invariants, 
the  loop  Invariant,  and  the  exit  test  all  hold: 

assert  f>2'Z«l,  i-z^-l,  zcN+1,  ets-t,  c<s  . 
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It  follows  that  the  given  program  halts  with  the  relations 

assert  (z-D^+i,  c+Kz^,  zcM*l 
holding  between  the  variables,  rather  than  with  the  desired  goal 
achieve  z^ic,  c<(z+l)2,  zeN  . 

The  cause  of  the  bug  was  the  inadvertent  exchange  of  the  initial  values  of  z  and  s  . 

Comparing  the  desired  goal  with  the  actual  Invariants,  we  note  that  the  former  may  be 
obtained  from  the  latter  by  replacing  z  with  z+l  and  c  with  c-l  .  Applying  the 
transformation  c  =*  c-l  to  the  program  statements  affects  only  the  exit  test  c<s  ,  which 
becomes  c-l <s  ,  or  equivalently  c<s  .  The  transformation  affects  two  other 

statements:  the  Initialization  z:=l  becomes  z+l:*l  and  the  loop-body  assignment  z:=z*l 
becomes  z+l:-z+2  •  These  resultant  assignments,  however,  are  "illegal",  inasmuch  as  an 
expression  such  as  z ♦  I  may  not  appear  on  the  left-hand  side  of  an  assignment.  Instead, 
the  expression  z + 1  is  given  the  initial  value  I  by  assigning  z:*0  ,  and  the  value  of  the 
expression  z*  1  Is  incremented  to  z* 2  by  the  "legal"  assignment  z:=z*l  . 

We  have  thus  obtained  the  corrected  program: 

I - 1 

|  P  begin  comment  debugged  integer  squart-root  program  | 

j  (z.z.r)  :«  (0.0.3)  I 

|  loop  assert  cis-t  J 

|  until  cSj  j 

j  (z.i.r)  :*  (z+l,  z+r, r+2)  | 

|  repeat  | 

|  assert  z^Se,  c<(z+l)^,  zcN  | 

|  end  .  | 

l _ l 

Katz  and  Manna  [1976]  suggest  that  when  there  is  insufficient  Information  to  prove 
either  the  correctness  or  Incorrectness  of  a  program,  It  may  nevertheless  be  desirable  to 
"debug"  the  program.  The  possibly  Incorrect  program  may  be  transformed,  using  known 
Invariants,  Into  a  new  program  which  is  unquestionably  correct.  Even  when  invariants  are 
found  for  an  Incorrect  program  —  It  Is  often  more  difficult  to  discover  invariants  for  an 
incorrect  program  since  It  may  in  fact  not  compute  anything  meaningful  —  there  may  be  no 
way  to  transform  them  Into  the  desired  specification.  It  then  becomes  necessary  to 
consider  the  sources  In  the  code  of  different  Invariants  separately. 
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3.  Corrtctntss  Considerations 

In  the  above  examples,  the  transformed  programs  were  correct;  i.e.  by  the  nature  of 
the  transformations,  the  transformed  programs  do  in  fact  satisfy  the  transformed 
specifications.  As  we  noted,  this  is  not  necessarily  the  case  with  any  transformation. 

Suppose,  for  example,  that  we  are  given  the  program: 

f - — - ! 

I  P :  begin  comment  array-minimum  program  \ 

|  {y,t)  :=  (0,  /<[0])  | 

S  loop  assert  z=mt'nM[0:y])  j 

j  until  y=n  | 

|  y  -  y*i  ! 

j  z  ;=  min(z,  4[y])  | 

j  repeat  | 

j  assert  z=mtnM[0:n])  | 

|  end  | 

I - - - 1 

for  finding  the  minimum  of  the  array  /<[0:n]  ,  and  we  wish  to  construct  a  program  to  find 
the  maximum  of  the  nonempty  array  g[l:n}.  The  given  program  achieves  the  output 
relation 

assert  z=min(4[0:n])  , 

while  the  output  specification  of  the  desired  program  is 
achieve  z=max(>f[l:n])  . 

Thus,  the  transformations  min  =>  max  and  0  I  suggest  themselves.  Though  in  this 
case  applying  these  transformations  happens  to  yield  a  correct  program,  such 
transformations  of  constant  symbols  do  not  necessarily  preserve  correctness.  Were  the 
function  min  not  explicitly  used  in  the  program,  e.g.  In  the  program 


J 


P begin  comment  alttrnatlvt  array-minimum  program 
(y,z)  :=  (0,,f[0]) 
loop  assert  z*minM[0:j]) 
until  y=n 
y  :=  y*l 

if  >f[y]<2  then  z  >  g[j]  fi 

repeat 

assert  zsminM[0:n]) 

end  , 


then  the  proposed  transformation  min  •+  max  would  clearly  not  work, 
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Global  transformations,  where  an  Input  variable  is  systematically  replaced  by  a 
function  of  only  input  variables,  or  an  output  variable  by  a  function  of  output  variables  or 
of  both  input  and  output  variables  (as  in  the  previous  examples),  always  yield  a  program 
satisfying  the  transformed  specifications.  However,  transformations  of  constant  symbols 
(as  in  this  last  example)  are  not  guaranteed  to  result  in  a  program  satisfying  the 
specifications.  Details  regarding  correctness-preserving  transformations  may  be  found  in 
an  appendix. 

Hence,  for  some  transformations,  correctness  must  be  verified.  For  this  purpose, 
invariant  assertions  are  utilized.  As  we  saw  above,  invariants  are  essential  in  our 
approach  to  debugging  too,  as  It  is  necessary  to  have  some  idea  of  what  the  program 
actually  does  before  It  can  be  corrected. 

Global  transformations  are  applied  to  all  invariants,  as  well  as  to  the  code.  Using 
these  transformed  invariants,  verification  conditions  for  the  new  program  may  be 
generated;  if  they  hold,  then  the  new  program  is  correct.  Alternatively,  applying  the 
transformations  to  the  (unsimpiified)  verification  conditions  of  the  original  program  yields 
verification  conditions  for  the  transformed  program.  It  is  best  if  the  conditions  are  given  in 
the  form  of  a  subgoal  tree,  reflecting  the  logical  steps  taken  in  constructing  the  program. 
This  subgoal  structure  may  be  expressed  in  purpose  statements. 

Returning  to  the  above  example,  we  wish  to  modify  the  first  version  of  the  min 
program  Pt ,  to  obtain  a  program  that  achieves  z-max(/f[l:n]) .  Applying  the 

transformations  min  =>  max  and  0  =*  I  yields 

I - 1 

|  Ph:  begin  comment  array-maximum  program  | 

|  ( y.z )  :=  (MM)  | 

|  loop  assert  z*max(A[  I:j»])  j 

|  until  y=n  | 

|  y  >  | 

j  z  :=  max(z,  yfjj;])  j 

j  repeat  j 

|  assert  z*max(A[l:n])  | 

{  end  .  j 

I  —  ■  .  . .  ...  —  I 

Using  the  new  invariants,  the  correctness  of  this  max  program  may  straightforwardly  be 
shown. 

On  the  other  hand,  applying  these  transformations  to  the  alternative  min  program 
P'  would  yield 


'rI'~  . 


PROGRAM  MODIFICATION  AND  DEBUGGING 


41 


I - 1 

|  P’\  begin  comment  suggested  array-maximum  program  | 

I  (y,z)  (0.  yl[03)  | 

|  loop  suggest  *=mcx(y<[0:^])  j 

I  until  y*n  | 

I  9  J*l  j 

j  if  A[y]<z  then  z  :»  A[y]  fi  j 

|  repeat  | 

|  suggest  z=max(>f[0:n])  | 

I  end  •  i 

l _ l 

We  have  replaced  the  assertions  with  suggestions,  since  correctness  is  not  guaranteed 
by  transformations  that  Involve  constants  (In  our  case  min  ).  Indeed  this  program  is 
incorrect,  since  the  loop  body  does  not  preserve  the  candidate  loop  invariant 

suggest  z=maxM[0:j»])  . 

In  the  next  subsection,  we  discuss  what  can  be  done  in  such  cases. 


4.  Completing  an  Analogy 

As  discussed  above,  the  verification  conditions  will  not  always  hold  for  a  given  set  of 
transformations.  There  could,  for  example,  be  unrelated  occurrences  of  0  in  the  min 
program  P*  (In  which  case  the  global  transformation  0  ■>  I  would  be  Inappropriate)  or 
the  function  symbol  min  might  not  appear  explicitly  In  the  program  at  all  (and  therefore 
the  transformation  min  ■»  max  would  be  ineffectual). 

The  program 

f -  - -  - - -  ’  ’  I 

I  P':  begin  comment  alternative  array-minimum  program  I 

|  ( y,z )  :•  (0,A[0])  | 

|  loop  assert  z*m<n(>f[0:y3)  j 

|  until  y*n  | 

I  y  >  >♦»  I 

j  if  A[y]<z  then  *:•  A[y)  fi  j 

j  repeat  | 

j  assert  z*min(yf[0:n])  j 

I  *nd  I 

l _ I 
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has  several  verification  conditions.  One  of  them  corresponds  to  the  loop-body  path  when 
the  conditional  test  is  true;  It  may  be  represented  as 

assert  y*n 
y  :=  y*\ 
assert  A[y"]<z 
*  A[y ]  . 

Since  the  program  is  correct,  we  know  that  the  loop  invariant  holds  each  time  control  is  at 
the  head  of  the  path,  and  that  if  that  path  is  taken,  then  the  invariant  holds  at  the  end  of 
the  path  as  well.  So,  assuming  that  the  invariant  z*min(A[0:y])  holds  and  that  the  exit 
test  y=n  is  false,  then  after  incrementing  y  and  setting  z  to  /f[y]  when  the  conditional 
test  /4[?]<z  Is  true,  the  Invariant  z*min(^[0:j])  again  holds,  for  the  new  values  of  y  and 
z  .  In  other  words,  we  have 

z-miniA[0:y])  A  y*n  A  j4|j+I]<z  a  ><|y»I]=min(4[0:y*l])  . 

Applying  the  two  transformations,  0  =?  1  and  min  =*  max  ,  to  this  condition  we  obtain 

z=max(A[l:y])  A  y*n  A  j4(j+I]<z  a  1  ]=m«xM[ l :y+ 1  ])  . 

However,  the  condition  no  longer  holds,  and  we  must  try  to  find  a  way  to  correct  that.  The 
condition  is  equivalent  to 

z=max(if[f :>])  A  y*n  A  if[y+l]<z  3  A[y*l]=max(max(A[l:y]),A[y*\])  , 

which,  in  turn,  simplifies  to 

o  A[y*l]-maxiz,  , 

or 

i4[y*l]<z  3  /f[y*l]iz  . 

Now,  matching  the  two  sides  of  this  implication,  suggests  completing  the  analogy  with  the 
additional  transformation  <  ^  fc  . 

This  transformation  in  feet  makes  all  the  verification  conditions  valid  and  yields  a 
correct  program  for  finding  the  maximum: 
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P":  begin  comment  alternative  array-maximum  program 
(y,z)  (l,A[13> 

loop  ester t  z*max(A[ 
until  y*n 

y  >  y*1 

if  A[y]iz  then  z  :*  A[y]  fi 

repeat 

assert  z*max(A[  l:n]) 
end  . 


Note  that  the  additional  transformation  could  be  localized  to  the  conditional  statement, 
since  its  verification  conditions  are  the  only  ones  that  fall. 

Were  0  not  to  appear  explicitly  in  the  initialization,  say  if  we  had  instead 

y  :*  1-1 
z  >  A\y ]  , 

then  the  verification  condition  for  this  path  —  after  applying  the  transformation 
(0  =>  I ,  min  =>  max )  —  would  be 

A[  1-1  ]=mox(A[  1:1-1])  , 

which  does  not  hold.  It  may  then  be  necessary  to  write  a  new  program  segment  that  would 
Initialize  the  loop  invariant  z«max(4[  l:y3)  by  setting  y  and  t  to  appropriate  values.  The 
goal 

achieve  z=max(/4[l:j])  varying  y,t 
can  be  satisfied  by  the  assignment 
< y.z )  :«  <1, -*[!])  • 

Were  0  to  appear  In  unrelated  parts  of  the  program  —  say  for  the  purpose  of 
illustration  that  we  had  an  additional  loop-body  assignment  y:*y+0  —  then  the 
transformation  0  =>  I  would  result  in  an  incorrect  program.  In  such  cases,  analysis  of  the 
(loop-body)  verification  conditions  would  suggest  not  applying  that  transformation  to  that 
occurrence  of  0  . 

Another  problem  that  sometimes  arises  in  program  modification  is  that  the 
transformations  only  achieve  part  of  the  output  specification.  In  such  cases,  It  may  be 
possible  to  extend  the  program  to  achieve  all  the  desired  parts  by  achieving  the  missing 
parts  at  the  onset  and  maintaining  them  invariantly  true  until  program  termination. 


Alternatively,  we  could  append  new  code  to  the  end  of  the  program  that  will  achieve  the 
additional  parts  —  without  "clobbering11  what  has  already  been  achieved  by  the  program. 


For  example,  consider  the  case  where  it  is  desired  that  P"  also  find  the  position  x  , 
in  the  array,  of  the  minimum  element  t .  We  can  extend  the  program  to 

achieve  t*A[x]  in  P"  varying  x 

by  maintaining  that  relation  as  an  invariant  throughout  the  execution  of  the  program. 
Synthesis  and  extension  are  treated  In  a  separate  chapter. 


3.  EXAMPLES 

In  this  section,  we  present  two  examples  of  program  modification.  We  begin  with  an 
Incorrect  real-division  program  and  show  how  to  correct  it.  This  is  the  same  program  as 
appeared  in  the  overview  chapter;  here  we  go  into  greater  detail.  Then  we  modify  a 
square-root  program  to  search  a  sorted  array  for  a  particular  element. 


Example  1:  Bad  Rtal  Division  to  Good  Real  Division. 

Consider  the  problem  of  computing  the  quotient  z  of  two  nonnegative  real  numbers  c 
and  d  ,  where  c<d  ,  within  a  specified  tolerance  t ,  0<<  .  The  given  program  is: 


Pti  begin  comment  bad  real-division  program 
assert  0Sc<d,  0<e 
( z.y )  :«  (0,1) 

loop  suggest  zic/d,  cfdiz+y 
until  yie 

if  d’(z+y)ic  then  z  :■  z+y  ti 
y  :•  y/2 

repeat 

suggest  z£c/d,  e/d<z*e 

end  . 
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The  Initial  assertion 
assert  0<c<rf,  0<r 

contains  the  input  specification  that  the  input  variables  c ,  d  and  e  are  assumed  to 
satisfy.  The  statement 

suggest  zic/d,  c/d<z+e 

at  the  end  of  the  program  expresses  the  output  specification  of  the  program  which  the 
program  is  believed  to  achieve.  But,  for  example,  r*l  ,  d* 3  ,  and  r* i/3  ,  which  satisfy 
the  input  specification,  yield  2*0  which  does  not  satisfy  the  second  conjunct  c/d<z*e  of 
the  output  specification. 

Before  we  can  debug  this  program,  we  must  know  more  about  what  it  actually  does.  ^ 
For  this  purpose,  we  first  annotate  the  program  with  loop  and  output  invariants.  The 
annotated  program  —  with  Invariants  that  correctly  express  what  the  program  does  —  is: 

assert  0<c<rf,  0<« 

(z.y)  :*  (0, 1) 

loop  assart  d‘z£c,  c<d>(z+ 2y) 
until  y<e 

if  d'(z*y)ic  then  t  :•  z*y  ti 
y  :*  y/2 

repeat 

assart  d‘z£c,  c<d*(z+2’*)  . 

The  desired  relation  c/d<z+e  Is  not  implied  by  the  output  invariants. 

We  now  have  the  task  of  finding  a  transformation  (correction)  that  transforms  the 
actual  output  invariant 

assert  d'Zic,  c<d'(z+2'«) 

into  the  desired  goal 

suggest  zie/d,  c/d<x*e  , 

or  equivalently, 


suggest  d'lic,  c<d‘{z+t)  . 


jt.Jt  v  »•  •  IT  .  '  H"  * : V  v-  ,  *  *.■ 


ii,,,1  j^ibui¥ 
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The  transformation  will  then  be  applied  to  the  program.  Accordingly,  we  would  like  to 
modify  the  program  in  such  a  manner  as  to  transform  the  insufficiently  strong  c<<Mz+2*e) 
into  the  desired  c<d*(z+«)  and  at  the  same  time  preserve  the  correctness  of  the  other 
conjunct  of  the  specification: 

(c<d'(z* 2*<)  c<d’(z*t),  d’zie  *♦  d'ZSc)  . 

The  expressions  c<rf*(z+2*<)  and  c<d‘(z*e)  differ  In  that  the  former  has  2*r  where 
the  latter  has  just  «  .  So  if  we  can  transform  2*»  •*<  ,  then  we  will  have  transformed  the 
specifications  as  desired.  In  order  to  transform  the  expression  2 •«  into  e ,  we  can 
transform  the  input  variable  t  into  e/2  .  We,  therefore,  apply  the  transformation 

e=>e/2 

to  all  occurrences  of  e  in  the  program;  all  other  symbols  in  the  program  are  left 
unchanged.  Only  one  executable  statement  —  the  exit  clause  —  is  affected,  giving 

Correction  i;  Replace  the  exit  clause  with 
until  yZe/2  . 

The  resulting  program  is: 

( - -  , 

|  Pt’:  begin  comment  corrected  real-division  program  j 

|  assert  0 <c<d,  0<e/2  | 

|  (*,>)  (0.1)  | 

|  loop  assert  d-zSc,  c<d'(z*2*y)  j 

j  until  yie/2  | 

j  if  d’(z+y)$c  then  z  >  z*y  fi  j 

I  y  :« yn  | 

j  repeat  j 

j  assert  d'zic,  c<d«(z+2*r/2)  .  j 


L 


J 
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Had  we  matched  the  output  invariants 
assart  d«zsc,  c<rf*(z+2,r) 
with  the  original  output  specification 
suggest  z<c/d,  c/d<z*t  , 
then  the  transformations 

(d  1 ,  c  *=>  c/d,  t  t/2 ) 

would  suggest  themselves.  Here  d  is  transformed '  into  the  identity  element  of 
multiplication,  so  that  d*z  =>  z  .  This  set  of  transformations  leads  to  the  same  program, 
except  for  the  fact  that  the  conditional  test  is  transformed  into  z*y<c/d  which  contains 
the  nonprimitive  division  operator.  Since  d  Is  positive,  this  nonprimitive  test  is  equivalent 
to  the  primitive  test  d'(z*y)<c  ,  which  may  be  substituted  for  it. 

Two  additional  debugging  transformations  may  be  obtained.  Again  we  begin  by 
comparing  c<d*(z+ 2*#)  with  c<d*(z+<) ,  but  this  time'  we  try  to  leave  e  unchanged.  We 
therefore  try  to  isolate  <  on  the  right  of  both  inequalities.  Accordingly,  we  wish  to 
transform 

(c/d-z)/ 2<e  ■>  c/d-z<e  . 

Matching  the  two  sides  of  the  inequalities  leaves  us  with  (c/d-z)/ 2  c/d-z  .  Multiplying 

both  by  2  ,  we  get 

c/d-z  =>  2 '(c/d-z)  *  2*c/d-2*z  =  c/(d/2)-2*z  . 

This  leads  to  the  transformations 
(c  =>  2*c,  z  =*■  2*z) 


or 

(d  d/2,  z  2-z)  . 

Applying  these  transformations  to  the  second  conjunct  d>zic  gives  either  d«2*z<2*c  or 
d/2*2*zSc  ,  both  of  which  simplify  to  d»zSc  .  This  is  exactly  what  was  wanted  and  no 
further  transformations  are  necessary. 

Doubling  z  and  either  doubling  c  or  halving  d  in  the  conditional  test  d*(z+y)£c 
yields  a  test  equivalent  to  d>(z+y/2)Sc  .  Transforming  z  Into  2*z  affects  two  additional 
statements:  the  Initialization  z:*0  becomes  the  "illegal"  assignment  2*z:»0  ,  which  is 
equivalent  to  the  "legal” 

z  :«  0  . 


Similarly,  the  assignment  z:«z+j»  of  the  the&*branch  becomes  2*z:*2,z*j> ;  in  order  to 


achieve  2*z*2*z'+j  varying  x  , 
we  can  assign 

z  :■  x+y/2  . 

No  other  statements  are  affected  by  either  of  the  two  modifications ;  thus  they  both  yield: 

Correction  2:  Replace  the  conditional  statement  with 
if  d»(z+y/2)£c  then  z  :«  z+j/2  fi  . 

In  general:  in  order  to  transform  /(u)  v  ,  for  any  expressions  u  and  v  and 
function  /  ,  we  may  transform  u  **  f~(v) ,  where  f~  is  the  Inverse  of  /  .  When  applying 
a  transformation  y  =>  f(y)  to  an  assignment  y-mf(y) ,  we  get  an  Illegal  assignment 

/(y)  g{f(y))  . 

To 

achieve  f(y)=g(f(y'))  varying  j  , 

we  can  apply  the  inverse  function  f  to  both  sides,  suggesting  the  assignment 

y  :<s  • 

Each  of  these  possible  sets  of  transformations  involved  one  of  the  input  variables  e  , 
c  ,  or  d  .  One  must,  however,  be  careful  when  transforming  input  variables,  since  the 
transformation  should  be  applied  to  the  input  assertion  as  well,  possibly  changing  the 
range  of  legal  Inputs  thereby.  In  our  case,  the  transformations  we  have  performed  pose  no 
problem:  Applying  e  e/2  to  the  input  assertion 

assert  0 $e<d,  0<e 

yields  the  equivalent  assertion 

assert  0 ic<d,  0<e/2  . 

Therefore,  halving  e  has  no  effect  on  the  input  range,  and  the  transformed  program  is 
correct  for  any  Inputs  satisfying  the  given  specification.  Moreover,  since  in  fact  the 
condition  c<2’d ,  rather  than  c<d ,  is  strong  enough  to  Imply  that  the  loop  invariants 
d'zic  and  c<d>(z+2’y)  hold  after  the  initialization  assignment  (z, ;)>((>,  I) ,  (this  is  easily 
seen  by  substituting  0  and  I  for  z  and  y  ,  respectively,  in  the  invariants),  we  can  relax 
the  Input  assertion  of  P%  to 


assert  0ic<2'd,  0<e  . 
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Then,  replacing  the  c  in  c<2'd  by  2*f  (or  the  d  by  d/2  )  still  yields  a  program  correct  for 
inputs  satisfying  c<d  ,  as  is  desired. 

Our  program  after  Correction  2,  annotated  with  appropriately  modified  invariants  is  (all 
c  have  been  replaced  by  2 *c  and  ail  i  by  2'Z  and  the  resultant  expressions  have  been 
simplified): 

f - 1 

|  P"\  begin  comment  good  real -division  program  j 

|  assert  0 Se<d,  0 <e  | 

I  ( z,y )  :=  (0,1)  j 

|  loop  assert  d*z£c,  c<d'(z*y)  ] 

j  until  y<e  | 

j  if  d‘(z+y/2)ic  then  z  :«  z*y/2  ft  j 

I  y  >  ?/2  \ 

|  repeat  J 

J  assert  d>z<c,  c<d'(z+e)  j 

|  end  .  j 

I _ _ _ I 


Example  2:  Real  Square-root  to  Array  Search. 
In  this  example,  we  show  how  the  square-root  program 


1 — 
1  py 

begin  comment  square -root  program 

“1 

assert  ail,  <>0 

(z, y)  :=  (I,«-D 

loop  assert  zsVa,  Va<z*y 

until  yie 

y  :«  y/2 

if  (z+y)2Ss  then  z  :■  t*y  fi 

repeat 

assert  zZVa,  Va<z*e 

[ _ 

end 

_J 
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may  be  modified  to  obtain  a  program  that  searches  for  the  position  z  of  an  element  b 
known  to  occur  in  an  array  segment  jf[l:n] .  The  array  Is  assumed  to  contain  nonnegative 
Integers  sorted  in  nondescending  order.  This  example  will  illustrate  a  number  of  difficulties 
that  may  be  encountered. 

Our  goal  is 

f - 1 

|  Pt:  begin  comment  array-starch  program  | 

|  assert  u<v^A[u]<A[v],  yf[u]eN,  6eta;M[l:n])  | 

|  achieve  A[z]=b  varying  z  | 

|  «nd  ,  ! 

I _ l 

where  N  is  the  set  of  nonnegative  integers  and  ta£(/f[l:n])  denotes  the  multiset  (bag) 
of  elements  in  the  array  segment  >4[l:n]  .  We  shall  allow  indexing  of  an  array  by  any  real 
number,  and  adopt  the  convention  that  the  intended  element  may  be  found  by  truncating 
the  index,  i.e. 

fact  /*[u]=ii[|uj]  . 

(In  a  similar  manner,  we  could  develop  a  program  following  the  Algol-60  convention  of 
rounding-off  the  Index.) 

The  desired  goal 

achieve  A[z]=b  varying  z 

Is  not  directly  comparable  with  the  output  invariants  of  the  given  program 
assert  ziVa,  Va<z*e  . 

So  we  first  develop  the  goal  somewhat. 

As  a  first  try,  we  replace  the  desired  goal  with  the  equivalent  conjunctive  goal 
achieve  yf[z]26,  bZA[z]  varying  z  , 

guided  by  the  fact  that  we  wish  to  achieve  an  equality,  while  the  given  program  achieves 
an  Inequality.  Since  we  are  dealing  with  Integers,  this  is  the  same  as 

achieve  /4[z]s6,  6<yf[z]+l  varying  z  . 

Accordingly,  we  are  looking  for  a  transformation 

ziV5AVa<z+r  -a  j4[z]£M6</4[z]«1  . 


and  try  to  compare  the  conjunct  xi'/S  with  A[t]ib  .  (Since  A  Is  commutative,  we  could 
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just  as  well  begin  by  trying  to  compare  zSVa  with  6<>f(z)+l  .)  Matching  the  two  sides  of 
the  inequality,  we  get  (2  *  A[z],  Vs  •*  b)  ;  In  order  to  obtain  Va  b  ,  we  can  let  a  ■*  b*  . 
Applying  these  transformations  to  the  remaining  conjunct  Va<z+r  leaves  us  with 
b<A[z]*e  *»  b<A [r]+ 1  ;  this  suggests  the  additional  transformation  r  ■»  1  . 

Applying  the  three  transformations 
(2  **  A[z),a  6^,*  r»  |) 
to  the  given  square-root  program  yields 

f - 1 

|  Pt:  begin  comment  propostd  array-search  program  | 

|  assert  ^21,  1>0  | 

|  (vl[z],>)  :=  (l.*2_|)  | 

j  loop  assert  if[z]<A,  6<^[z]+y  j 

|  until  y<l  j 

I  y  ■-  y/2  | 

|  if  then  A[z ]  :«  A\z]*y  fi  | 

|  repeat  j 

|  assert  A[z]<b,  6</f[z]+I  | 

lend  j 

»  r 

There  are,  however,  a  number  of  problems  with  this  program,  the  insurmountable  one  lying 
In  the  conditional-branch  assignment  >f[*]>>f[z]+y .  The  problem  Is  that  the  original  goal 
stated  that  only  2  Is  an  output  variable,  while  the  array  A  is  an  input  variable  which  may 
not  be  modified  by  an  assignment.  Furthermore,  there  is  no  way  to 

achieve  i4[z]M[z']+>  varying  z  , 

since  the  value  Alz'l+y  Is  not  known  to  appear  in  A  at  all. 

So  we  must  look  for  another  alternative.  Since  A[u"]bA[[u j]  ,  it  is  sufficient  to 
achieve  ^[[z ]]*b  varying  z 
In  order  to  achieve  our  goal 

achieve  A[z]*b  varying  2  . 

At  this  point,  we  would  like  to  extract  z  from  within  the  expression  >f[[zj]  ,  as  it  appears 
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by  Itself  In  the  output  Invariants  of  the  given  program.  To  this  end,  we  use  the  function 
pas(A ,  u )  which  gives  the  position  of  the  (rightmost)  occurrence  of  the  element  u  in  the 
array  A  j  It  is  an  inverse  of  the  array  Indexing  function  >4[s]  ,  l.e. 

fact  pos(A,uU Z  whan  ueA 

(  Z  is  the  set  of  all  Integers), 

fact  A[pos(A,  u)]=u  whan  ueA  , 

and 

fact  pos(A,u)>»-l  when  A[v}*u  . 

Instantiating  the  second  fact  with  b  for  u  yields  A [pos(A ,  b))*b  ,  since  It  is  given  that 
beA  ;  thus,  in  order  to 

achieve  if[|zj]=ft  varying  z  , 

it  suffices  to 

achieve  pos(A,b)*[z J  varying  z  . 

Applying  how  the  definition  of  (uj  , 

fact  w=|uJ  m  vSuAu<v«IAveZ  , 
we  obtain  the  conjunctive  goal 

achieve  pos{A,b)Sz,  z<pos{A,b)*\,  f>cs[A,bHl  varying  z  . 

Since  the  third  conjunct  pos(A,  b)eZ  is  always  true,  we  are  left  with  the  goal 
achieve  pos{A,b)Sz,  z<pos(A,b)+l  varying  z  . 

The  current  goal  is  still  not  readily  comparable  with  the  output  specification  of  the  real 
square-root  program, 

assert  zSVa,  Va<z*t  : 

while  for  the  array-search  program  the  output  variable  z  appears  on  the  right-hand  side 
of  the  i  relation  and  on  the  left-hand  side  of  the  <  relation,  for  the  square-root  program 
the  sides  are  reversed. 

One  possible  solution  is  to  transform  the  predicates  S  and  <  .  To  get 
zSVs  «*  zzpMA,  b)  , 
we  may  apply  the  transformations 
(S  e  i,  e  po${A,b))  . 
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To  obtain  the  second  transformation  Vs  «*  pos(A,b) ,  we  let  a  =*  poiiA.b'p-  .  Applying 
these  transformations  to  the  conjunct  Va<x*t  leaves 

pos(A,b)<z*t  pos(A,b)*\>z  . 

Transposing  to  get  just  pos(A,b)  on  the  left  of  the  inequalities,  gives 
pos(A,b)<z*e  pos(A,b)>z~l  , 

so  we  add  the  transformations  «*»>,*■»  -1) .  All  together  we  have 
(2  «*•  i,  a  *>  pos(A,  ft)2,  <  =>  >,  t  <+  -1)  . 

Applying  these  transformations  to  the  given  square-root  program  yields 

( z.y )  :=  (\,pos(A,  ft)2-l) 
loop  suggest  zipos(A.b),  pos(A,b)>z*y 
until 
y  :=  y/2 

if  {z*y)^pos(A,  ft)2  than  *  :■  z+y  ti 

repeat 

suggest  zZpos(A.b),  pos(A,b)>z~l  . 

Simplifying  the  expressions  In  the  program,  we  get 

(z.y)  :*=  (),pos(A,b)2-l) 
loop  suggest  zipot(A.b),  pos(A,b)>z*y 
until  jfc-1 
y  :»  y/2 

if  z*yipos(A,b )  than  z  :■  z*y  ti 

repeat 

suggest  zzpos(A.b),  pos(A,b)>z- 1  . 


Before  we  try  to  eliminate  the  nonprimitive  function  pos  from  the  transformed 
program,  we  attempt  to  verify  the  correctness  of  the  program  as  Is.  The  loop  invariants 

assert  ztpos(A.b),  pos(A,b)>z*y 

along  with  the  exit  condition 

until  jfc-l 

clearly  Imply  the  desired  output  invariant 

assert  pot(A,b)Sz,  z<pos(A,b)+ 1  . 
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Furthermore,  the  loop-body  path  preserves  the  loop  Invariants  for  both  cases  of  the 
conditional. 

The  problem  Is  with  the  verification  condition  for  the  initialization  path:  the  assignment 

(z , y):*(l ,  pos(A ,  6)^-1)  does  not  initialize  the  loop  invariants.  So  we  replace  the 
initialization  with  the  new  subgoal 

assert  u£tO/f[u]£jf[p],  yf[u]eN,  6efca|(yf[l:n]) 
achieve  z>pos(A,b),  pos(A,b)>z+y  varying  z,y  . 

Since  we  are  given  that  b  appears  within  the  segment  <4[l:n],  we  can  achieve  the 
relation  zZpos(A.b)  by  letting  z*n  .  Now  we  can  achieve  pos(A,b)>z*y  by  insisting  that 
z*y- 0  ,  for  which  we  initialize  y  to  -z=-n  . 

The  verification  condition  for  termination  Is  (3fefcl)(-n/2^£-l) ,  i.e.  by  repeatedly 
halving  y  ,  which  has  the  Initial  value  -n  ,  the  exit  test  y£-l  must  at  some  point  become 
true.  This  is  indeed  the  case.  Thus,  all  the  verification  conditions  hold  and  the 
transformed  program  is  correct. 

Finally,  the  conditional  test  z*yipos(A,  b)  ,  that  contains  the  nonprimitive  function  pos  , 
may  be  replaced  by  A[z*y*l]>b  .  That  the  two  tests  are  equivalent,  may  be  deduced  from 
the  Input  specification 

assert  u<voA[u]SA[v ] 

and  the  definition  of  pos . 

Our  program  now  looks  like  this: 

(z,y)  (n.-n) 

loop  assert  zipos(A.b),  pos(A,b)>z*y 
until  ^2-1 
y  :«  y/2 

if  yf[z+y+l]>6  then  z  :■  z*y  ti 

repeat 

assert  zZp<u(A,b),  pos(A,b)>z- 1  . 

If  we  transform  the  program  variable  y  by  y  +  -y  and  simplify,  we  get 
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|  Pt:  bt|in  comment  array-search  program  | 

|  assort  ustOjf[u]Si4[v],  >4[u]€W,  6€twjM[l:n])  | 

j  (z.y)  :■  (n,n)  j 

|  loop  assort  zZpos(A.b),  pas(A,b)>z-y  j 

|  until  yi\  | 

I  y  >  >/2  | 

j  if  A[z-y*  l]>6  than  t  :«  *-j  fi  j 

j  repeat  j 

j  assert  A[z]*b  j 

j  end  .  j 

I _ I 

Note  that  transforming  a  variable  that  does  not  appear  in  the  program  specifications,  such 
as  y  ,  cannot  affect  what  the  program  does,  only  how  it  does  it. 

Having  found  one  satisfactory  solution,  let  us  return  to  the  point  where  we  compared 
the  desired  goal 

achieve  zipos(A.b),  pos(A,b)*\>z  varying  z 
with  the  output  invariants 

assert  ziVa,  Va<.z*e  . 

An  alternative  way  to  transform  the  relation  i  in  the  desired  goal,  into  i  and  <  into  >  , 
without  transforming  the  predicates  themselves,  would  be  to  multiply  both  sides  of  the 
inequalities  by  - 1  .  We  would  thereby  obtain  the  equivalent  goal 

achieve  -zS-poj(A,b),  -pos{A,b)-\<-z  varying  z  . 

Comparing  the  output  Invariant  ziVa  with  the  first  conjunct  of  this  goal,  suggests  the 
transformations 

(z  -z,  -pos(A,b))  . 

To  obtain  Va  =>  -pos(A.b) ,  we  would  like  to  use  a  *>  (-poj(A.b))^  ,  but  since  pos(A.b)  is 
positive,  that  would  give  Va  =*  pos(A,b ) ,  rather  than  -pos(A,b)  as  desired.  As  there  ia 
no  easy  way  out  of  this  problem,  we  drop  this  possibility. 

There  Is  another  way:  Just  as  u£v  Is  equivalent  to  u<v*  I  for  Integers  u  and  v  ,  for 
real  numbers  we  can  transform  an  expression  of  the  form  uiv  Into  one  of  form  u<v+€  , 
where  €  is  an  arbitrarily  small  real  number.  Similarly  u<o  la  equivalent  to  u*(Sv  .  The 
t's  may  then  be  eliminated  from  the  resulting  program.  Thus,  we  may  compare 

assert  z<Va*(,  Va<z*r 
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with 

achieve  z<pos(.A,b)*l,  pcs(A,b)<z+(  , 
which  suggests  the  set  of  transformations 
(a  pos(A,  bp,  t  x-l*€,  t  +  1)  . 
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Applying  these  transformations  to  the  square-root  program  yields 

assert  pos(A,bfe  1,  IX) 

(*-!♦«. y)  :*  U,pos(A,blP-l) 

loop  assert 

until  yi\ 
y  j/2 

if  (z-l+e+j)^p«OM)^  than  r-Ul  :•  x-l+t+j  fi 

repeat 

assert  t-\*iipes{A,b),  ^or(>i,6)<z-l+t+l  . 

The  transformed  conditional  test  (z-l*t*y^ipos(A,b)^ ,  may  be  simplified  to 
z-l*i*yipos(A,b) ,  l.e.  z-\*y<pos(A,b) .  To  remove  the  nonprimitive  function  pos  ,  we 
replace  the  test  with  A[z+y]£b  .  Replacing  the  initialization  and  the  illegal  assignments, 
we  obtain  the  transformed  program: 

1 - 1 

|  P,':  begin  comment  array-search  program  | 

|  assert  u<v3if[u]Si4[v],  yf[u]€kJ,  6€ta;(/f[l:n])  | 

j  U,y)  :*  (l.n)  j 

|  loop  assert  z<pos{A,b)+l,  pos(A,b)*\iz*y  j 

j  until  y<>\  | 

I  y  y/2  | 

j  if  >4[z^]S6  then  z  :«  z*y  fi  | 

j  repeat  | 

j  assert  A[z]=b  j 

I  *nd  -  I 

l _ l 

Replacing  the  Initialization  In  general  requires  rechecking  the  verification  condition  for 

termination;  In  this  case,  (3f€N)(n/2^Sl)  must  hold  for  the  program  to  terminate,  as 
Indeed  it  does. 

This  array-search  program  may  be  given  a  more  conventional  appearance  if  we  can 
replace  z*y  (the  right  bound  of  the  search),  which  appears  twice  in  the  program,  with  just 
y  .  To  effect  z*y  ■*  y  ,  we  use  the  global  transformation 

y+y-z  , 

since  z+(y-z)*y  .  Since  the  right-hand  side  of  this  transformation  contains  a  variable  other 
than  the  transformed  variable  y ,  the  application  of  the  transformation  Is  a  bit  trickier: 
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wherever  there  is  an  assignment  to  t ,  even  if  y  is  not  changed,  we  must  consider  what 
happens  to  the  transformed  value  of  y  .  Thus,  the  conditional  branch  assignment  z:-z*y 
must  be  considered  as  though  it  were  (z,y)>(z+y,y) ,  which  is  transformed  into 
(z,y-z):*(z+(y-z),y-z) . 

Replacing  all  occurrences  of  y  in  the  program  with  y-z ,  and  using  the  appropriate 
achieve  statements  in  place  of  the  transformed  assignments,  we  get: 

achieve  z*l,  y-z-n  varying  z,y 
loop  assert  z<pos(A,b)+ 1,  pos(A,b)+ \<y 
until  y-zi\ 

achieve  }-z=(/-z)/2  varying  y 

if  A[y]Sb  then  achieve  z-z'+(y'-z'),  y-z-y'-z'  varying  z.y  fi 
repeat 

assert  j4[z]«6  . 


The  initialization  subgoal 

achieve  z=l,  y-z-n  varying  z.y 
yields  the  assignment 

{z.y)  :=  (1, n+l)  . 

Isolating  y  on  one  side  of  the  equality  In  the  subgoal 
achieve  y-z-(y'-z)/2  varying  y  , 

yields 

y  :*  (z*y)/2  . 

The  conditional-branch  subgoal 

achieve  z«z'+(j'-x'),  y-z-y'-z'  varying  z.y 
yields  the  assignment 

C*.  jf)  :*  (y,2y-z)  . 

The  program,  so  far,  Is: 
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(z,y)  :=  (l,n+l) 

loop  assort  z<pos{A,b)*\,  pos(A,b)+\Zy 
until  y-zi  I 
y  :■  (*+y)/2 

if  ^03^6  then  (z,y)  (j,2 •y-z)  fi 

repeat 

assert  ^[z]=fc  . 


There  are  still  a  few  more  changes  that  may  be  made:  By  pushing  the  loop-body 
assignment  to  y  into  the  conditional  statement,  we  get 

if  A[(z+y)!2]<b  then  (z,y)  :■>  ((z+j)/2,j)  ®lse  J  '•  (z+y)f 2  fi  . 

Now.  by  eliminating  the  superfluous  assignment  y:*y  and  Introducing  a  temporary  variable 
t  to  contain  the  value  (z+y)/2  ,  we  get 

t  :=  (z*y)/2 

if  A[(]<b  then  z  t  else  y  :«  f  fi  . 

Our  final  version  of  the  array-search  program  is: 

i - 1 

J  P,':  begin  comment  conventional  array-search  program  | 

|  assert  uSuD/f[u]S/f[v],  /4[u]eN,  6etej'(i4[l:n])  | 

j  ( z.y )  :=  (l,n+l)  j 

|  loop  assert  z<pos(A,b)*\,  pos{A,b)+l£y  j 

j  until  y-zi\  j 

j  t  :*  (mj)/2  j 

j  if  then  z  :■  t  else  y  :«  t  fi  j 

j  repeat  j 

j  assert  A[z]*b  | 

|  end  .  | 

l _ l 


This  chapter  has  Illustrated  the  use  of  analogy  to  modify  and  debug  programs.  The 
next  chapter  shows  how  similar  techniques  may  be  used  to  abstract  and  Instantiate 
programs. 
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1.  INTRODUCTION 

When  confronted  with  a  new  task,  a  person  will  often  notice  a  resemblance  between 
It  and  some  previous  accomplished  task.  To  conserve  effort,  he  is  likely  to  adapt  the 
knowledge  he  learned  on  those  occasions  to  the  new  problem  at  hand.  After  solving  a 
number  of  similar,  problems,  he  might  form  a  general  paradigm  for  solving  such  problems  by 
supressing  the  Inconsequential  particulars  of  the  individual  instances.  We  term  the 
process  of  forming  a  general  scheme  from  Instances  of  the  problem  abstraction ,  and  that  of 
applying  a  general  scheme  to  a  particular  problem  instantiation. 

In  the  programming  case,  we  are  given  a  set  of  concrete  programs,  presumably 
related  in  some  way,  and  would  like  to  derive  an  abstract  program  schema.  The  programs 
are  assumed  to  be  annotated  with  their  Input-output  specifications  and  with  sufficient 
Invariant  assertions  to  demonstrate  their  correctness.  The  first  step  is  to  find  an 
abstraction  of  the  set  of  specifications  of  all  the  programs.  This  yields  an  abstract 
specification  that  may  be  Instantiated  to  any  of  the  given  concrete  specifications.  For 
each  of  the  given  specifications  there  corresponds  an  abstraction  mapping  that  when 
applied  to  the  concrete  specification  will  yield  the  abstract  specification.  That  same 
mapping,  applied  to  the  given  program,  yields  an  abstract  program  schema.  Conversely, 
the  instantiation  mapping  that  yields  the  concrete  specifications  of  a  program  when 
applied  to  the  abstract  specifications,  will  yield  the  corresponding  concrete  program  when 
applied  to  the  abstract  schema. 

A  schema,  however,  may  not  be  applicable  to  all  possible  instantiations  of  its 
specifications.  In  that  case,  the  schema  is  accompanied  by  an  input  specification 
containing  conditions  that  must  be  satisfied  by  the  instantiation  to  guarantee  correctness. 
These  preconditions  may  be  derived  from  the  verification  conditions  which  serve  to  bridge 
the  gap  between  the  assertion  language  in  which  the  specifications  are  stated  and  the 
programming  language  in  which  the  program  is  coded.  In  cases  where  the  preconditions 
are  not  satisfied  by  a  particular  instantiation,  analysis  of  the  unsatisfied  conditions  may 
suggest  modifications  that  will  help  satisfy  the  conditions. 

To  date,  little  research  has  been  done  on  program  abstraction.  The  STRIPS  system 
(Flkes,  Hart  and  Nilsson  [1972])  generalized  the  loop-free  robot  plans  it  generated;  the 
HACKER  system  (Sussman  [1975])  "subroutinlzed"  and  generalized  the  "blocks-world" 
plans  It  generated,  but  was  limited  In  this  respect  by  Its  use  of  executions,  rather  than 
verification  proofs,  to  determine  what  program  constants  could  be  generalized.  Recently, 
Gerhart  [Apr.  1976]  and  Gerhart  and  Yelowitz  [1976]  have  also  advocated  the  use  of 
program  schemata  as  a  powerful  programming  tool  and  have  recommended  the 
hand-compilation  of  a  handbook  of  such  program  schemata  to  aid  human  programmers. 
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(See  Yelowitz  and  Duncan  [1077]  for  a  detailed  example  of  the  use  of  schemata  as  an  aid 
in  program  verification  and  Misra  [1078]  for  an  approach  to  the  specification  of 
schemata.) 

In  this  chapter,  we  apply  program*modification  techniques  to  abstraction.  To 
generalize  the  common  aspects  of  two  programs  P  and  Q  and  form  a  program  schema, 
we  first  find  the  set  of  transformations  for  modifying  P  into  Q .  Recall  that  to  modify  a 
program  P  so  as  to  obtain  a  program  Q ,  we  look  for  an  analogy  P  Q  between  the 
specifications  of  P  and  Q .  The  analogy  suggests  a  set  of  transformations  that  when 
applied  to  the  program  P  will  yield  a  program  satisfying  the  specifications  of  Q .  Each 
transformation  is  of  the  form  t  =>  / ;  all  occurrences  of  t  in  the  program  P  are 
transformed  into  / .  For  each  such  transformation,  the  corresponding  abstraction 
transformation  for  P  Is  t  =*  o  and  for  Q  Is  f  =*  v ,  where  v  Is  a  new  variable  symbol. 

We  are  tacitly  assuming  that  the  specifications  of  our  programs  are  expressed 
formally  and  that  this  specification  does  express  the  desired  behavior  of  the  program. 
This  is  not  a  trivial  point;  it  is  not  uncommon  for  errors  or  omissions  to  be  made  in  the 
original  specification  of  a  program.  Balzer,  Goldman,  and  Wile  [1977]  have  been 
investigating  the  possibility  of  constructing  a  formal  specification  from  informal  and 
incomplete  specifications. 

Another  problem  inherent  in  our  use  of  analogy  for  program  modification  and 
abstraction,  is  that  the  two  specifications  that  are  to  be  compared  may  have  little 
syntactically  in  common.  When  the  specifications  are  not  syntactically  similar,  it  is 
necessary  to  rephrase  the  given  specifications  In  some  equivalent  manner  that  brings  their 
similarity  to  the  fore.  This  Is  clearly  a  difficult  problem.  In  our  examples,  we  indicate  what 
may  be  done  in  some  such  cases;  In  general,  some  form  of  means-end  analysis  seems 
appropriate. 

In  the  next  section,  we  present  several  examples  of  abstraction  and  instantiation. 


2.  EXAMPLES 

Three  examples  follow;  in  the  first,  we  derive  a  schema  for  linear  search;  the  second 
is  an  Iterative  implementation  of  a  recursive  definition;  the  third  is  a  more  general  binary 
search  than  the  one  we  saw  in  Chapter  II. 
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Example  1 :  Minimum /Maximum  Schema. 

Consider  the  following  two  programs: 

f  I 

|  Pt:  begin  comment  minimum-value  program  j 

|  assert  neM  I 

j  ( z.y )  :*  (^[0],  0)  j 

|  loop  assert  z^O:}],  | 

|  until  y=n  I 

I  y  >  n  j 

j  if  then  z  :=  ><[31]  fi  j 

|  repeat  | 

j  assert  z<if[0:n]  | 

|  end  | 

l _ l 

and 


1 — 
1  Qr 

begin  comment  maximum-position  program 

- 1 

1 

assert  m,  neZ,  min 

(z.y)  :=  (n.n) 

loop  assert  A[z]>A\y\n],  yel 

until  y=m 

y  :=  j-l 

if  A[y]>A[z]  then  z  y  fi 

repeat 

assert  yf[z]£yf[m:n] 

1 - 

end  , 

_ ) 

where  the  construct  p[u'.v]  Is  shorthand  for  (Vt)(u£{Sv)p(C) ,  for  any  predicate  p  ,  i.e., 
p  holds  for  all  values  f  In  the  range  [u:v]  .  The  output  specification  of  the  first  program 
P,  is 

assert  z£>4[0:n]  ; 

it  finds  a  value  z  smaller  than  any  appearing  In  the  array  segment  A[0:n]  .  The  second 
program  Q,  finds  the  position  z  of  a  maximum  element  in  the  array  segment  vf[m:n]  ;  its 
output  specification  Is 

assert  ^[z]2/4[m:n]  . 

(For  simplicity  we  have  not  included  the  output  specifications  zeg[0:n]  and  mSzSn  of 
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Px  and  Q  ,  respectively.) 


In  the  previous  chapter  we  saw  how  one  may  derive  such  programs  one  from  the 
other.  The  obvious  analogy  between  the  specifications  of  the  two  programs  is  that  where 
the  specifications  of  Pt  have  t,  and  0 ,  the  specifications  of  Q,  have  2  ,  A[z]  , 
and  m  ,  respectively: 

**  *  **  A[z),  0  <=»  m)  . 
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Applying  the  transformations 
(£  i,z  >f[z],  0  *♦  m) 

to  the  output  specification  of  Pt  transforms  it  Into  that  of  Q, .  However,  applying  these 
transformations  to  the  program  Pt  does  not  yield  a  program  satisfying  the  specifications 
of  Q, .  This  is  because  the  program  Pt  makes  use  of  properties  of  the  constant  i  that 
do  not  apply  to  i  .  Similarly,  applying  the  transformations 

(i  =»  S,  x  «*■  pos(A,  z),  m  0) 

(where  pos{A ,  z)  is  the  position  of  the  element  z  in  the  array  A  )  transforms  the 
specification  of  Q,  Into  that  of  P, ,  but  does  not  yield  a  correct  program.  As  we  saw  in 
the  last  chapter,  to  obtain  a  correct  program  we  must  examine  the  verification  conditions. 

Consider  the  path  initializing  the  loop  In  P , : 
assert  neli 

(z.y)  :=  (yf[0],0) 

suggest  zS>f[0:y],  yeN  . 

We  are  given  that  neN  ,  and  must  show  that  the  loop  Invariants  z</f[0:y]  and  yeN  hold 
after  initializing  z  to  j4[0]  and  y  to  0  .  That  is,  to  verify  this  path,  we  must  have 

neN  3  /f[0]5/f[0:0]  A  OeN  . 

Applying  the  transformations 

S  *  2  ,  z+A[z]  ,  and  0+m 

to  this  condition  yields 

neN  3  A[m]iA[m:m]  A  meN  . 

The  first  consequent  is  equivalent  to  /4[m]^4[m]  and  clearly  holds;  we  are 

left  with  the  consequent  meN .  This  path,  the,  will  be  correct  if  the  condition  meN  is 
satisfied. 

Next,  we  consider  the  loop>exit  path 

assert  zS>f[0:y],  yeN 
assert  y«n 
suggest  zSif[0:n]  , 

l.e.  the  loop  invariants  plus  the  exit  test  y*n  must  Imply  the  output  specification 
z£<4[0:n]  .  The  transformed  condition  is 

>4[z]fc/4[m:y]  A  yeN  Ajm  5  >f[z]2/4[m:n]  , 
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which  clearly  holds. 

Finally,  we  consider  the  loop-body  path 

assart  z£A[0:y],  yeN 
assart  y*n 
y  :•  y*  1 

if  ^[y]<z  then  x  :■  >f(y]  fi 
suggest  z<>f[0:y],  yeW  . 

To  verify  this  path,  we  must  show  that  the  loop  invariant  continues  to  hold  if  the  exit  test 
is  false  and  the  loop  body  is  executed,  for  both  cases  of  the  conditional  statement,  if 
A\y+\]<*  before  executing  the  path,  then  the  then-branch  of  the  loop, 

assert  ziA[0:y),  y€N 
assert  y*n 

y  :■  y*\ 

assert  A[y]<z 

z 

suggest  zSA[ 0:y],  yell  , 
is  taken.  In  that  case,  we  must  have 

zSA[ 0:y]  A  ycN  A  y*n  A  >f[y*l3<z  o  /f[y*l]S<f[0:y+l]  A  y+leW  . 

Similarly,  for  the  alternative  path,  we  need 

zS/f[0:y]  A  yeN  A  jun  A  -,M[y*l]<z)  o  zS^[0:y*l]  A  y+lcN  . 

Applying  the  transformations  to  these  two  conditions  gives 

i*[z]£/<[m:y]  A  yeN  A  y*n  A  >4ty+l]</t[z]  o  ^[y*l]2>t[m:y*l]  A  y+lcN 
and 

A[z]2A[m:y]  A  ycN  A  y*n  A  -»(<4[y* I ]<^[*])  3  i4[z]fc/f[m:y+l]  A  y*lcW  . 

Consider  the  second  of  these  two  verification  conditions.  The  consequent  y+lcN 
clearly  holds  at  the  end  of  the  loop  body,  since  yeN  held  before  the  path.  The 
consequent  A[z)iA[m'.y* I ]  Is  partially  Implied  by  the  conjunct  A[z)ZA[m:y ]  appearing  on 
the  left-hand  side  of  the  implication;  only  >4[z]2/4[y+l]  Is  not  implied.  So  we  look  for 
additional  relations  with  which  to  complete  the  analogy.  On  the  left-hand  side  we  have  the 
conjunct  -<M[y+l]<>f[z])  while  the  desired  ^[zl^ty*!]  Is  equivalent  to 
~'('4[y+l  ]>><[*])  •  This  suggests  the  additional  transformation 
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<  ->  >  . 

With  this  transformation  tha  first  verification  condition  holds  as  well. 

Thus  the  four  transformations 

(S  «*  fc,  z  -a  A[z],  0  +  m,  <  *  » 

will  yield  a  correct  program  for  finding  the  position  of  the  maximum  provided  that  the 
condition  mcM  is  satisfied.  In  the  same  manner,  It  may  be  shown  that  the  transformations 

(i  S,  z  pos(A ,  *),  m  «*  0,  >  *  <)  , 

when  applied  to  Q, ,  will  yield  a  correct  program  for  finding  the  minimum. 

Now  that  we  have  a  complete  analogy  between  the  two  tasks  Pt  and  Q, ,  viz. 

(S  2:,  r  «*  .4(2],  0  «=*  m,  <  **  »  , 

we  attempt  to  generalize  it  to  obtain  an  abstract  program  schema  embodying  the 
underlying  technique  of  the  program.  The  generalization  of  the  two  predicates  S  and  St 
Is  a  new  predicate  variable  a  ;  similarly,  the  generalization  of  C  and  >  is  &  .  The 
generalization  of  z  and  A[z]  is  z ,  since  2  may  easily  be  transformed  into  A[z]  (but 
not  vice  versa);  similarly,  the  generalization  of  the  constant  0  and  variable  n  is  n.  In 
this  manner,  we  obtain  the  abstraction  mappings 

(S=>a<=2,z«i>z*=  A[z], <*♦£<=»  , 

l.e. 


(S  •*  o,0  -►  «,<  •+(}) 
will  generalize  Pf  and 

(i*a,ie  pos(A,  2),  >  0) 

will  generalize  Q, . 

Applying  the  first  set  of  transformations, 

(S«e  cr,0  «♦!*,<  *0)  , 

to  the  output  specification  of  Px  (or  the  second  set  to  Q, )  yields  the  abstract 
specification 

assert  ot(z,^[m:n])  . 


This,  then,  will  be  the  output  specification  of  the  schema.  To  obtain  the  desired  schema, 
we  apply  the  transformations  to  P ,  yielding 
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( z,y )  :•  (A[m],m) 
loop  assert  a(z,  A[m'.y]),  yeN 
until  y=n 
y  :«  y*\ 

if  0(>f[y],  z)  then  z  :«  fi 
repeat 

assert  a(z,^[m:n])  . 

Since  the  abstraction  transformations  involve  constants,  we  must  examine  the  schema's 
verification  conditions.  Those  conditions  that  cannot  be  proved  will  remain  as 
preconditions  for  applicability  of  the  schema. 

The  verification  condition  for  the  Initialization  path  is 
a(i4[m],  >f[m])  A  meN  ; 

thus,  if 


mcN 


and 

o(u,u) 

for  all  u  ,  then  that  path  is  correct.  The  condition  for  the  exit  path  is 
a(z,  A[m:y])  A  yeN  A  y*n  3  a {z,  Aimin'})  , 
which  is  clearly  the  case.  The  remaining  two  conditions  for  the  twrf  loop-body  paths  are 
oTz,  A[m.y})  A  jcN  A  flMfr+l].*)  3  aWjj+l], A[m:y+l})  A  y+lcN 

end 

a(z,  A\m:y])  A  jieN  A  -<0(i41j>+lJ,z)  3  a(z, /f[m:?+l])  A  y+leN  . 

The  conjunct  j+leN  clearly  holds  In  both,  and  since  we  are  already  requiring 
aG4[y+l],  >t[y+l]) ,  that  leaves 

a(z,W[m:y])  A  yeN  A  0C4[j+l],«)  3 

and 

a(z,/<[m:j])  A  jeN  A  -<fi{A[y ♦!],*)  3  <*M[y+l],z)  . 

These  conditions  may  be  generalized  (ef.  Boyer  and  Moore  [1976])  by  replacing  the 
expressions  A[miy)  and  A\y+\]  that  appear  on  both  sides  of  the  implications  with 
universally  quantified  variables  u  and  v  ,  respectively.  The  generalized  conditions  are 

o(z,u)  A  £(»,*)  3  a (v,u) 
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and 

a(z.u)  A  -<0(»,z)  o  a(t,v ) 

(the  con June  ts  yeH  have  been  dropped  aa  y  does  not  at  all  appear  in  the  consequents). 
Finally,  there  is  a  termination  condition 

(3feN)  0«{*»  ; 

transforming  It  gives 

Ofeli)  m*f»n  , 

or  equivalently,  since  meN  , 

neN  A  m£n  . 

The  schema,  with  Its  preconditions  listed  in  its  input  assertion,  is 

I  ~  “  . . "  "  "  —  "  1  I 

|  5,:  begin  comment  minimum  /maximum  schema  | 

|  assert  a(u,u),  a(u,z)A0(z,v)3a(v,u),  a(z,  u)A-t0(v,  z)do(z,  v),  m.ncN.  mS«| 

|  (z,y)  :*  ( )  | 

|  loop  assert  a(z,  A[m:y]),  jieN  | 

|  until  y=n  | 

I  y  >  r*  I 

J  if  ${A\y],  z)  then  z  :■  /f[j]  fi  | 

|  repeat  | 

|  assert  a(z,^[m:n])  | 

|  end  .  | 

l _ i 

Any  instantiation  that  satisfies  the  preconditions  is  guaranteed  to  yield  a  correct  program. 
Clearly,  the  predicates  a  and  8  that  appear  In  the  schema  should  be  instantiated  to 
primitives  available  in  the  target  language,  otherwise  they  must  be  repleced  by  equivalent 
predicates  for  the  schema  to  yield  an  executable  program. 

In  a  similar  manner,  we  could  use  £>,  as  the  basis  for  the  abstraction;  we  would  obtain 
a  somewhat  different  schema  with  the  same  output  specification. 

Note  that  A  may  be  considered  to  be  a  function  as  any  other.  Thus,  this  schema  can 
be  Instantiated  to  find  the  position  or  value  z  of  the  minimum  or  maximum  of  any  function 
over  the  domain  of  integers  In  the  range  [m:n] .  For  example,  to  find  the  position  z  of 
the  minimum  of  the  function  /  in  the  interval  [0:m]  ,  l.e. 


70 


r*.. 


IT 


i - 1 

|  /?,:  begin  comment  /unction  minimum  program  | 

|  assert  meM  j 

|  achieve  /(z)*/[0:m]  varying  z  | 

j  end  .  | 

I _ _ _ i 

we  compare  this  goal  with  the  abstract  specification  of  the  schema 
assert  a(z,i4[m:n])  . 

The  following  instantiation  is  obvious: 

(a  **  S,  z  **  /(z),  A  /,  m  ■*  0,  n  m)  . 

Applying  this  instantiating  to  the  preconditions 

assert  a(u,u),  a(z,  u)A0(v,  z)3a(v, u),  a(z, u)A-<0(v,  z)do(z,  i»),  m.ncN.  min 

yields 

assert  uSu,  z<uA0(v,z)DViu,  z<uA-tf(o,  z)oziv,  O.mcN.  0<m  . 

The  first  condition  hoids  since  S  is  reflexive;  the  last  two  follow  from  the  input 
specification  meN  .  That  leaves  ziuAfHo,  z)Dviu  and  ziu A->0(v,  z)oziv  .  The  latter 
suggests  completing  the  analogy  by  letting  0(v,  z)  *»  v>z  ;  then  the  other  condition 
ziuAz>voviu  holds  as  well. 

Applying  the  complete  instantiation  mapping, 

(a  =>  i,z  =>  f(z),  A  => /,  m  ■»  0,  n  n,  0  •+  <)  , 
to  the  schema  yields 

(/(*).?)  :=  tf(O).O) 
loop  assert  /(z)S/[0:j/],  ycN 
until  y=m 
y  :*  ?♦» 

if  /(?)</(*)  then  /(z)  :■  f(y)  ti 

repeat 

assert  /(z)s/[0:mj  . 


Replacing  the  Illegal  assignments,  we  get  the  concrete,  correct  program 
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|  Rt:  besin  comment  function  minimum  program 
assert  mefti 

(z.y)  :«  (0,0) 

loop  assert  /(z)S/[ 0:y],  yeN 
until  j»« 

y  :=  ji+l 

if  f(y)<f(z)  then  i  :*  y  fi 
repeat 

assert  /(z)S/[0:m] 


The  same  abstraction  process  would  work  were  we  given  the  two  recursive  programs 


P,'U A[0:n]): 

besin  comment  recursive  minimum-value  program 
assert  neM 

if  n-0  then  z  :*  ^[0] 

else  /,/(z,^[0:n-l]) 

if  ii[n]<z  then  z  :•  ii[n]  fi 
fi 

assert  ziA[0:nl,  neN 


(?,'(*.  y<[m:n3): 

begin  comment  recursive  maximum-position  program 
assert  m.neZ,  mSn 
if  m»n  then  z  :«  n 

else  Q/(z,  /i[m+l:n]) 

if  A[m]>A[z]  then  z  :>  m  fi 
fi 

assert  A[z]iA[m.n],  meN 


Abstracting  these  two  programs,  we  would  obtain  the  scheme 


r*  * 

-4.? 
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S/(x, 

begin  comment  recursive  minimum /maximum  schema 

assert  a(u,u),  a(x,  u)A/5(v,  z)?a(v,  u),  a(z,u)/\->0(v,z)Da(z,v)t  m.neZ,  mSn| 
if  n*n  then  x  :■  A[m] 

else  Pfb.Alm'.n- 1]) 

if  6(A[n],z)  then  x  :■  j<[n]  fi 
fi 

assert  a(x,  A[m:n]),  ncN 

end  . 


Example  Zt  Associative  Recursion  Schema. 


Consider  the  two  programs: 


1 — 
1  F*: 

begin  comment  factorial  program 

- , 

1 

assert  acM 

(x.j)  :=  (l,«) 

loop  assert  j!;z*=a! 

until  j*0 

(z.jr)  :» 

repeat 

assert  x«=a! 

1 - 

end 

_ 1 

PROGRAM  ABSTRACTION  A NO  INSTANTIATION 


73 


I - 1 - 1 

|  Q,:  befln  comment  array-summation  program  | 

|  assert  ncW  | 

j  b,y)  :«  (0,  m)  | 

j  loop  assert  | 

|  until  y*n+\  | 

j  iz.y)  :«  j 

j  repeat  | 

|  assert  | 

|  end  .  | 

l _ i 


Matching  the  two  output  specifications 
assert  z=a! 
and 

assert  z=Sfsm^[f] 
suggests,  as  one  possible  analogy, 

(u!  **  £fEtt^[f  ].  a  **  m)  . 

The  two  functions  u!  and  generalize  to  a  function  variable  /(u) ;  the  input 

variables  a  and  m  generalize  to,  say,  a  : 

(u!  «»/(u)  ♦»  Ef.u>f[f].  aeten)  . 

Thus,  we  get  the  abstract  output  specification 
assert  z=/(«)  . 

Both  programs  consist  of  a  single  loop;  their  respective  loop  invariants  are 
assert  y*z=a! 
and 

assert  . 

Matching  the  Invariants,  after  applying  the  transformations  already  found,  gives 
/(j)*z-/(a)  ♦*  /(?)♦*•/(«)  , 
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and  we  derive  the  additional  aspect  of  the  analogy 
•  *  h  «=  ♦  . 

Applying  the  corresponding  transformations  to  the  loop  Invariants  we  obtain  the  abstract 
Invariant 

Assart  h(fiy),z)=f(a)  . 

Now,  we  must  consider  the  verification  conditions.  The  initialization  condition  of  P,  is 
a!*l«a!  , 

and  applying  the  transformations  we  get 

!)=/<«)  ; 

on  the  other  hand,  applying  the  transformations  to  the  Initialization  condition  of  • 

f.  #  gives 

A(/-(a),0)»/(a)  . 

To  unify  the  two,  we  add  to  the  analogy 
1  ■=>  r  «=  0  , 

* 

and  obtain  the  abstract  condition 
h{f(a),  *)=/(«)  . 

The  loop-exit  condition  derived  from  Pt  Is 
h{f(y),  z  )*/(«)  A  y*0  o  z«/(«)  ; 
from  Q, ,  we  get 

h(f(y),z)*f{a)  A  y*n+l  d  *«/(«)  . 

With  the  abstraction 

0=»n«sn+l  , 

we  get 

»  fiifiy),  z)*f(a)  A  y*n  o  z*f(a)  , 

or,  equivalently 


T-,  . 


h(f(n),  z)«z  . 
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For  the  loop-body  paths,  we  have  the  conditions 
h(f(y),  z)*f(a)  A  j inn  3  h{J{y-\),h{y,  z))*f{a) 
and 

A  y*n  d  1), *W&], *))-/<«>  • 

for  Pt  and  ,  respectively.  To  unify  j-l  *>  y*\  and  y  A[y ]  ,  we  need  the  additional 

abstractions 

(♦  =>  g  <=-,¥>=»  i  A)  , 

where  y>  is  the  Identity  function,  l.e.  p(u)*u  .  This  yields 

h(f(y),  z)~f{a)  A  yen  a  h(f(g(y,  I)),  h(i(y),  z))*f(a)  , 
or  equivalently 

y*n  o  h(f(g(y,\)),h(i(y),z))*h(f(y),z)  . 

The  complete  abstraction  is 


(u!  /(u)  1.  o«*ae«  m, 

0=>n<=n+l,+  =»g<=-,v>=>i<=^)  . 
Applying  it  to  Q*  ,  end  collecting  all  the  preconditions,  we  derive  the  schema 


|  St:  begin  comment  associative  recursion  schema 

|  assert  A(u,«)=u,  h(f(n),  z)«x,  y*nz>h(f(g(y,  I)),  h(i(y),  z))*h(f(y),  z) 

j  ( z,y )  :«  («,«) 

|  loop  assert  h(J(y),  z)=/(a) 

|  until  y*n 

|  (z,y)  :«  (h(i(y),  z),  g(y,  1» 

|  repeat 

j  assert  *=/(«) 


In  this  manner  we  have  obtained  a  general  schema  for  computing  a  function  /(a) .  It 
applies  to  recursive  functions  /(*)  such  that  /(»)**  Is  a  unit  of  an  associative  and 
commutative  function  h  ,  and  f{u)*h(f(g(u,  l)),l(u))  when  yen  .  The  schema  is  similar  to 
one  of  the  recurslon-to-iteration  transformations  of  Burstatl  and  Darlington  [1977]. 

To  see  how  this  schema  may  applied  to  another  problem,  consider  the  specifications 
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|  Rt :  begin  comment  list-reversal  program  I 

|  assert  rej  I 

|  achieve  z=reverse(r )  varying  z  j 

I  ®nd  .  j 

I _ I 

where  S  is  the  set  of  all  lists,  and  reversed)  is  a  list  containing  the  elements  of  r  in 
reverse  order.  Assume  that  we  are  also  given  two  relevant  facts  about  reverse  : 

fact  reverse{{))  =  () 

and 

fact  reversed)  *  reverst{tail{u.))'{head(u))  when  u*  ()  , 

where  u* v  concatenates  the  two  lists  u  and  v  ,  headlu )  Is  the-first  element  of  the  list 
u  ,  and  tail(u)  is  a  list  of  all  but  the  first  element,  and  ()  is  the  empty  list. 

An  initial  comparison  of  the  schema's  output  specification  z=/(a)  with  the  new 
specification  z=reverse(r)  suggests  the  instantiation 

/  =>  reverse  . 

instantiating  the  precondition 

y*  n  o  hlflgly,  I )),  h(i(y),  z))=h(f(y),  z) 

gives 

y*n  d  Hreverse(g(y,  1)),  h(i(y),  z))*h(rever:e(y),  z)  . 

By  the  second  of  the  above  two  facts,  we  have  that  reversely )  may  be  replaced  by 
reverse(tail(y))»(Aead(y)) ,  provided  that  y  Is  not  the  empty  list  () .  This  suggests 
Instantiating  n  ()  to  obtain 

y*()  3  h(reverse(g(y,\)),h{ay),z))~hlreverse(tail(y))'(head(y)),z)  . 

The  function  reverse  appears  on  the  two  sides  of  the  equality,  so  we  try  to  generalize  this 
condition  by  replacing  both  occurrences  of  reverse  with  an  arbitrary  list  u  .  To  do  that, 
we  must  first  unify  reverse(g(y,  D)  with  reverseltailly))  by  Instantiating  glu,  v)  =>  taillu)  . 
We  are  left  with  the  condition 

A(u,  HHy),  z))~h(u'lheadly)),  z)  . 

Similarly,  we  unify  Hu)  with  {headiu)) ,  the  list  containing  just  the  first  element  of  u  , 
obtaining 

h{u,  hlv,z))~h{u'v,z)  . 

This  matches  with 


i 
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fact  , 

by  Instantiating  h  **  • ,  l.e.  •  Is  associative. 

The  Instantiations  we  have  found  are 

(f  =*  reverse,  n  *=>  ().  g (u,  u)  =*  tail(u),  i(u)  **  {headiv)),  h  *>  •)  . 

Applying  them  to  the  other  preconditions 
assert  A(u,«)*u,  h(f(n),z)=z 

yields 

assert  u*r=u,  r«w«(())*z=z  . 

But  reversed) M)  and  ()*z«z  ,  since  the  empty  list  ()  is  an  identity  element  of  the 
function  Thus,  the  second  condition  holds;  the  first  suggests  letting  «=»(). 

The  completed  instantiation  is 

(f  =*  reverse,  n  =>  (),  g(u,  v)  =o  tail(u),  i(u)  ( head{u )),  /!=»•,»=»())  . 

In 


all,  we  have  derived  the  following  program 

I - 1 

|  Rt:  begin  comment  list  reversal  program  I 

j  assert  reJ 

|  z  :=  0 

i  y  >  r 

|  loop  assert  reverse(y)'Z-reverse(r) 

|  until  j=() 

|  z  :=  (head(y))>z 

|  y  :=  tail(y) 

|  repeat 

|  assert  z=reverse(r) 

|  end  . 

I _ I 


Example  3t  Binary-Search  Schema. 

In  the  general  overview,  we  saw  how  a  binary-search  schema  was  abstracted  from 
two  programs,  one  for  real  division  and  the  other  for  square  roots.  In  this  example,  we 
shall  begin  with  the  array-search  program  Instead  of  the  square-root  one;  a  more  general 
schema  will  result. 
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Consider  the  following  two  annotated  binary-search  programs,  Pf  and  Q, 


P}:  begin  comment  real-division  program 
assert  0 ia<b,  0 <e 
(z,y)  :=  (0.1) 

loop  assert  b-zZa,  a<b-(z+y) 
until  yie 

y  :=  y/2 

if  b'(z*y)£a  then  z  :*  z+y  ti 
repeat 

assert  b'Z<a,  a<M*+r) 
end 


Q,:  begin  comment  array-search  program 

assert  u<io4[u]s,4[j>],  bebag(A[  1  :n]) 

U,y )  :■  (n,n) 

loop  assert  z>pos(A,b),  pos(A,b)>i~y 
until  ?<( 
y  y/2 

if  A[z-y*V[>b  then  z  :«  z-y  fi 

repeat 

assert  /f[z]<6,  i<<f[z*l] 
end  . 


Recall  that  when  an  index  u  of  an  array  A  is  not  an  integer,  the  intended  element  is 

44 

The  analogy  between  the  specification  of  P , , 
assert  b-zSa,  a<b>(z+e) 
and  the  specification  of  Q, , 

assert  >4[z]S&,  6<4[z+l]  , 


(u-vSw  **  tu[v]iu.,a  *»  A,u<vw  ♦»  tKu[w],«  **  1) 


The  corresponding  abstraction  mappings  are 
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(ifv&w  «»  a(u,  v,  w)  «=  a)[y]Su,  a  **  a  +*  A, 

u<wu>  •+  0(u, v, w)  +•  v<u[u>], »•»<<=!)  . 

Applying  these  transformations  to  P%  yields  the  schema 

(z.y)  >  (0,1) 

loop  assart  a(b,x,o),  0(a,  b,  z+y) 
until  yie 
y  >  y/2 

if  a(b,z+y,o)  then  z  :«  z+y  ft 
repeat 

assert  a(b,  z,a),  0(a,b,z+t)  . 

In  the  same  manner  as  in  previous  examples,  we  derive  the  precondition 
0(a,b,u )  A  uiv  3  0(a,b,v) 
for  the  loop-exit  path,  and 

-<a(b,  u,  a)  d  0(a,  b,  u) 
for  the  loop-body  path. 

The  verification  condition  for  the  loop-initialization  path  Is 
a(b,  0,  a)  A  0(a,b,  1)  . 

However,  if  we  were  to  abstract  Q,  instead,  we  would  get  an  Initialization  condition 
a(b,  n,  a)  A  0(a,b,  0)  . 

This  suggests  generalizing  the  constant  0  in  Pt  and  n  In  Q.  to  j  and  1  and  0  to  *  . 
In  this  manner,  we  would  obtain  the  Initialization 

(*.?)  >  0.*) 

with  the  unified  preconditions 
a(b,j,a )  A  0(a,b,k)  . 

Alternatively,  we  can  just  preface  the  loop  with  an  unachieved  subgoal 

achieve  a(b,z,a),  0(afb,z+y)  varying  z,y  , 

stating  that  the  loop  Invariant  must  be  achieved  before  entering  the  loop. 

Adopting  the  second  option  we  get  the  schema 
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I  5,:  begin  comment  binary-search  schema  I 

j  assert  0(a,b,u)/\u*VD0(a,b,v),  ->a(b,u,a)o0(o,b,u)  | 

|  achieve  a(b,z,a),  0(a,b,  z*y)  varying  z,y  | 

loop  assert  a(b,z,a),  0(a,b,z+y) 

|  until  yie  | 

I  y  yf2  | 

I  if  a(b,z+y,a )  then  z  :«  z*y  fi  I 

j  repeat  j 

j  assert  a(i>,z,a),  0(a ,b,z+e)  | 

|  end  .  j 

l _ l 

It  is  a  general  program  schema  for  a  binary  search  within  a  tolerance  with  the  abstract 
output  specification 

assert  a(b,z,a),  0(a,b,z*e)  . 

To  illustrate  how  this  search  schema  may  be  used,  we  consider  a  variation  on  the 
square-root  program: 

I - 1 

|  R}:  begin  comment  variant  square-root  program  | 

|  assert  0 <rf,  Kc  | 

|  achieve  z-d<Jc,  Sc<z  varying  z  | 

|  end  ,  | 

»  » 

that  is,  the  result  z  may  only  be  greater  than  the  square-root  of  c  by  less  than  the  given 
d  .  We  would  like  to  Instantiate  the  binary-search  schema  to  yield  such  a  square-root 
program. 

In  order  to  match  this  output  specification  with  that  of  our  schema: 
assert  a(b,z,a),  0 (a,b,z*e)  , 

we  let  the  constant  e  be  the  constant  expression  -d  and  obtain  the  transformations: 

(a  »♦  c,  a(6,  z,  u )  ■*  VuSz,  0(u,  b,  v)  i><  Vu,  e  +  -d)  . 

The  preconditions 

assert  0(a,b,u)Ausvo0(a,b,v),  -<a(b,u,a)o0(a,b,u) 
instantiate  to 


assert  u<VcAuivov<Vc,  -’(Vc Su)pu<VF  . 
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The  second  condition  holds,  while  the  first  does  not.  To  get  the  first  condition  to  hold,  we 
need  uZv  ,  rather  than  uiv  ,  suggesting  the  additional  transformation  i  -►  Z . 

To  satisfy  the  Initialization  condition,  we  need  to 

achieve  a(b,x,a),  0 (a,b,z*y)  varying  x.y  , 
i.e. 


achieve  Veil,  x+y<VF  varying  x,y  . 

We  note  that  since  l<c ,  we  have  VRc  and  c+(l-c)*I<-/r.  Thus,  both  conjuncts  hold 
when  we  let: 

(x.y)  :=  (c,  l-c)  . 

(An  alternative  would  have  been  to  take  -c  for  y  ,  since  c+(-c)=0<vF.) 

The  Instantiated  schema  is: 

assart  0<d,  l<c 
(x.y)  :=  (c.  l-c) 
loop  assert  Vt<x,  z*y<Vc 
until  yZ-d 
y  :*  y/2 

if  Vciz+y  then  x  :«  x*y  ti 

repeat 

assert  VcSx,  x-d<VF  . 

However,  since  a  involves  the  square-root  function  itself,  the  conditional  test  is  not 

primitive  and  must  be  replaced.  It  can  be  replaced  by  ci(z*y)^  since  c  and  z*y  are 
nonnegative  (  0 Sc  follows  from  the  input  specification;  the  relation  0 £z*y  may  be  shown 
to  be  a  global  invariant).  Thus,  we  have: 


r 


|  /?,:  begin  comment  variant  squau-root  program 
|  assert  0 <d,  Kc 

|  (z,y)  >  (c,  l-<) 

|  loop  assert  Veiz,  z+y<VF 

I  until  yi-d 

|  y  •*  y!7 

|  if  c£(z+j)2  then  z  z*y  ft 

I  repeat 

I  assert  Vciz,  z-d<VF 

I  end  . 

I _ I 


In  the  last  two  chapters,  we  have  explored  modification  and  abstraction  techniques; 
in  the  next  two  chapters  we  develop  helpful  tools  for  synthesizing  and  annotating 
programs. 
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1.  INTRODUCTION 

Recently,  researchers  have  tried  to  gain  Insight  Into  the  haphazard  art  of  programming. 
This  has  led  to  the  development  of  "structured  programming"  which  has  been  defined  by 
Hoare  as  "the  task  of  organizing  one's  thought  in  a  way  that  leads,  in  a  reasonable  time,  to 
an  understandable  expression  of  a  computing  task".  One  of  the  guidelines  of  structured 
programming  is  that  "one  should  try  to  develop  a  program  and  its  proof  of  correctness 
hand-in-hand"  (Gries  [1974]).  Much  has  been  written  on  the  subject,  including  the  works 
of  Dijkstra  [1968,1976],  Dahl,  Oijkstra,  and  Hoare  [1972],  Wirth  [1973,1974],  Conway 
and  Gries  [1973],  and  others. 

The  idea  is  to  construct  the  desired  program  step  by  step,  beginning  with  the  given 
input  and  output  specifications,  in  each  step  the  current  goat  is  solved,  transformed  into 
another  goal,  or  reduced  to  simpler  subgoals.  Each  stage  is  correct  if  its  predecessor  is, 
thereby  guaranteeing  the  correctness  of  the  final  program.  Our  purpose  in  this  chapter  is 
to  formalize  some  of  the  strategies  of  structured  programming,  thereby  contributing  to  its 
automation.  As  we  have  seen,  such  methods  are  needed  to  complement  the  techniques  of 
program  modification  and  instantiation. 

One  of  the  major  hurdles  in  automatic  structured  programming  lies  in  the  formation  of 
loops.  Recent  synthesis  systems  have  variously  dealt  with  this  problem.  Buchanan  and 
Luckham  [1974]  require  the  user  to  supply  the  skeleton  of  the  loop,  and  the  system  fills  in 
the  details.  Sussman  [1976]  described  his  HACKER  system  that  creates  Iterative  and 
recursive  loops  with  no  guarantee  of  correctness.  Darlington  [1976],  Manna  and 
Waldinger  [1976,1977],  and  others  have  described  a  technique  of  recursion  formation  and 
the  need  to  sometimes  strengthen  the  original  specifications  for  that  purpose.  The  system 
described  in  Green  [1976]  assumes  extensive  a  priori  programming  knowledge,  such  as  an 
experienced  programmer  would  have.  Duran  [1976]  investigated  the  use  of  loop 
invariants  In  the  synthesis  of  programs,  along  lines  similar  to  our  iterative  loop  strategy. 
For  a  survey  of  these  and  other  spproaches  to  automatic  program  synthesis,  see  Biermann 
[1976], 

The  next  section  contains  an  overview  of  the  steps  involved  in  the  synthesis  of  a 
simple  program.  In  Section  3,  we  introduce  some  programming  rules;  in  the  fourth  section, 
the  rules  are  employed  in  the  syntheses  of  several  programs.  A  final  section  deals  with 
the  problem  of  extending  a  program  to  achieve  additional  goals.  When  synthesizing  code 
to  extend  a  program,  care  must  be  taken  to  ensure  that  the  original  specifications 
continue  to  be  satisfied. 
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2.  OVERVIEW 

In  this  overview,  we  Informally  describe  the  synthesis  of  a  simple  program;  the  steps 
in  the  strategies  themselves  are  explained  In  the  next  section. 


Program  synthesis  begins  with  an  Initial  goal  of  the  form 

f - 1 

|  P:  begin  comment  desired  program  | 

|  assert  input  specification  j 

|  achieve  output  specification  varying  output  variables  | 

|  «nd  ;  | 

I _ I 


The  task  is  to  expand  the  goal  into  a  segment  of  code  whose  execution  will  terminate  with 
the  relation  expressed  in  the  output  specification  holding  between  the  variables.  By 

varying  output  variables  , 

we  Indicate  that  only  those  variables  may  be  set  by  the  program;  other  variables 
appearing  In  the  specifications  are  input  variables.  The  statement 

assert  input  specification 

specifies  the  set  of  values  of  the  input  variables  for  which  the  synthesized  program  is 
expected  to  work. 

From  these  specifications,  an  annotated  program  of  the  form 

assert  input  specification 
purpose  output  specification 

code  to  achieve  specifications 
assert  output  specification 

Is  constructed.  When  control  reaches  the  end  of  the  program,  the  variables  must  satisfy 
the  output  specification.  The  code  must  be  primitive,  in  other  words,  it  may  not  itself 
contain  achieve  statements  or  nonprfmitive  operators.  Thus,  a  program  synthesizer 
"compiles"  the  high-level  achieve  statements  Into  lower-level  "code".  The  purpose 
statement  Is  a  comment  expressing  what  It  Is  that  the  following  code  was  intended  to 
achieve. 

It  is  usually  not  possible  to  generate  code  directly  from  the  initial  goal.  Rather,  at 
each  stage  of  the  construction,  a  current  goal  Is  replaced  by  one  or  more  new,  and 
hopefully  more  readily  achievable,  subgoals,  that  if  and  when  achieved  will  imply  the 
desired  relation.  Each  step  must  preserve  correctness,  i.e.  satisfying  the  new  goals  must 
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yield  a  correct  program  satisfying  the  current  goal.  Thus,  the  final  program  is  guaranteed 
to  satisfy  the  original  specifications. 

In  general,  at  each  stage  in  the  synthesis  of  a  program  there  is  more  than  one 
unachieved  subgoal,  and  for  each  subgoal  there  may  be  a  number  of  possible 
transformations  that  can  be  applied.  Whenever  a  given  choice  turns  out  to  be 
unsuccessful,  a  different  possibility  must  be  tried.  We  do  not,  however,  address  here  the 
important  issue  of  how  to  guess  which  may  be  the  best  choice  at  any  particular  point. 
Kant  [1877]  describes  a  system  that  guides  the  choices  made  by  a  synthesis  system 
based  upon  an  analysis  of  expected  time  and  space  requirements.  Annotation  techniques 
facilitate  such  analyses  and  could  be  employed  in  conjunction  with  the  synthesis. 


Consider  the  goal 


i  i 

|  Pe:  begin  comment  gcd  program  | 
|  assert  acN,  6cN+l  J 

|  achieve  z=gcd(a,b)  varying  z  ( 


(where  N*1  is  the  set  of  positive  Integers),  aimed  at  constructing  a  program  that  sets 
the  variable  z  to  the  greatest  common  divisor  (gcd)  of  two  nonnegative  integers  a  and 
b  . 

Were  gcd  a  primitive  function  of  the  target  language,  then  this  goal  could  be 
achieved  by  a  simple  assignment  statement: 

z  :*=  gcd(a.b)  . 

But  having  no  primitive  gcd  function  available,  the  goal  must  be  achieved  in  stages 
utilizing  domain-specific  knowledge  about  gcd .  Furthermore,  we  assume  that  the  set 
constructor  {  .  .  .  }  and  max  function  are  not  primitive,  or  else  we  could  use  the 
definition 

fact  gcd(u,  v)*max[weN:w|uAw|s}  when  u,  ueZ 
(where  the  predicate  w|u  means  that  v  divides  u  evenly)  to  assign 
z  >  max{n«€N:cv|aAa/|6}  . 

Note  also,  that  were  it  not  specified  that  only  z  may  be  varied,  the  goal  could  be 
achieved  by  the  assignments 

(*,«)  :■  <8, 0) 

since  a>0  and  z-b  Imply  z*gcd(a,b) . 
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Not  having  any  way  to  directly 

achieve  z*gcd(a,b)  varying  z  , 

the  first  step  in  the  synthesis  might  be  to  introduce  program  variables  whose  values  may 
be  manipulated  by  the  program  so  as  to  achieve  the  goal.  To  this  end,  the  goal  may  be 
replaced  by  the  conjunction  of  two  subgoais 

achieve  z=gcd(s,t),  u*gcd(s,  t)ou*gcd(a,  b)  varying  z,s,t  . 

The  second  subgoal  u=gcd(s,t)DU*gcd(a,b )  requires  that  for  any  value  u  ,  if  u  is  equal  to 
gcd(s,  t)  —  for  some  values  of  the  new  program  variables  s  and  t  —  then  it  is  also  equal 
to  the  desired  value  gcd{a,b) .  In  particular,  if  the  variable  z  has  the  value  gcdU.t)  at 
the  same  time  as  the  second  subgoal  holds,  then  the  original  goal  z*gcd(a,b)  is  satisfied. 
Since  the  Implication  u-gcd(s,t)ou-gcd{a,b )  must  hold  for  all  values  of  u  ,  it  is  equivalent 
to  the  simpler  gcd(s,t)-gcd(a,b) .  Our  current  goal,  then,  is 

achieve  z=gcd(s,t),  gcd(s ,  f)*gcd(a ,  b)  varying  z.j.r  . 

At  this  point,  we  would  like  to  simplify  this  goal,  which  is  composed  of  two  conjuncts, 
by  splitting  it  into  two  consecutive  nonconjunctive  subgoals.  Choosing  to  first  achieve 
gcd{s,0=gcd(a,b)  and  then  z=gcd(s,  0  ,  we  get  the  two  subgoals 

achieve  gcdU,t)-gcd(a,b)  varying  t,  t 
achieve  z-gcd{s,l)  varying  z,s,l  , 

each  of  which  is  simpler  than  the  conjunctive  goal.  However,  in  so  doing,  one  must  ensure 
that  achieving  the  second  subgoal  will  not  "clobber"  what  was  accomplished  by  the  first 
subgoal.  This  point  will  be  taken  up  later. 

To  achieve  the  first  subgoal 

achieve  gcd(s,t)*gcd(a,b)  varying  s,t  , 
it  suffices  to 

achieve  U,  t)=(a,  b)  varying  s,  t  ; 
to  achieve  the  latter,  we  can  assign 
0.0  :«  (a,b)  . 

Matching  zmgcd{s,t)  with  the  domain-specific  knowledge 
fact  gcd(0,  u)=u  when  ucN*l  , 

stating  that  if  u  is  positive,  then  the  gcd  of  u  and  0  is  u ,  we  get 
(}40,(>»u,z4u),  i.e.  z*gcd(s,t)  if  j-0  and  z*fcN+l.  Thus,  the  remaining  subgoal 

achieve.  z*gcd(s,t)  varying  z,;,r 


may  be  replaced  by  the  sufficient 


achieve  z-t,  fcN+l,  j= 0  varying  z,s,t  . 

Again,  we  may  split  the  conjunctive  goal  into  two  consecutive  aubgoals 

achieve  ;=0,  fcN+1  varying  s,l 
achieve  z=t  varying  z  . 

Notice  that  we  have  allowed  the  first  subgoal  to  vary  s  and  r ,  but  not  z  ,  while  the 
second  goal  may  vary  only  z  ,  leaving  the  values  of  4  and  t  unchanged.  Achieving  the 
second  goal,  say  by  assigning 

z  :=  t  , 

will  therefore  leave  4=0  and  feN+J  once  those  relations  have  been  achieved  by  the 
preceding  subgoal. 

It  remains  to 

achieve  4=0,  feN+1  varying  s,t  . 

To  achieve  4=0  ,  we  do  not  want  to  simply  assign  4:=0  ,  since  this  will  undo  the  previous 
assignment  s:-a  ;  on  the  other  hand,  we  must  vary  the  value  of  s  since  a  is  not 
necessarily  0  .  To  resolve  this  dilemma,  recall  that  we  set  (4,  f)=(a,  ft)  only  in  order  to 
achieve  the  relation  gcd{s,t)=gcd(a,b) .  So,  if  we  can  "protect"  this  latter  relation  while 
achieving  4=0  ,  rather  than  protect  the  stronger  (s,t)=(a,b) ,  then  when  4=0  is  achieved, 
the  desired  relation  gcd{s,t)*gcd(a,b)  will  still  hold..  The  protected  relation 
gcd(s,t)=gcd(a,b)  is  termed  an  invariant  assertion ;  it  is  associated  with  a  specific  point  in 
the  program  segment,  and  expresses  that  part  of  the  goal  that  has  already  been  computed 
whenever  execution  reaches  that  point,  (ft  is  the  inductive  assertion  used  In  Floyd's 
[1067]  method  of  proving  program  correctness.) 

An  alternative,  but  equivalent,  way  of  viewing  this  solution  is  as  follows:  The  original 
purpose  In  having  introduced  the  variables  s  and  t  and  set  (s,  t)=(a, b)  was  to  enable  us 
to  compute  z*gcd(s,t )  rather  than  z*gcd(a,b ) .  So,  we  must  make  sure  that,  though  the 
value  of  4  is  changed,  it  still  suffices  to  achieve  z*gcd{s,t ) ,  l.e.,  achieving  z*gcd{s,  t )  for 
the  new  value  of  s  will  Imply  z*gcd(s,t)  for  the  old  value  as  well.  The  relation  z*ged(s,t) 
Is  then  called  an  invariant  purpose',  it  expresses  the  ultimate  goal  throughout  the 
computation.  (It  Is  the  assertion  used  for  subgoal  induction,  see  Manna  [1971]  and  Morris 
and  Wegbrelt  [1977]). 

To  achieve  4=0  while  protecting  the  invariant  relations,  we  construct  a  loop  of  the 

form 


PROGRAM  SYNTHESIS 


69 


loop  assert  gcd(s,t)=gcd{a,b) 
purpose  z=gcdU,t) 
until  s=0 

approach  J»0  varying  s,t 
repeat  . 


The  statement 

assart  gcd(s,t)-gcd(a,b ) 

contains  the  invariant  assertion  of  the  loop;  the  statement 
purpose  z=gcd(s,t ) 

contains  the  invariant  purpose.  For  a  relation  to  be  an  invariant  assertion  of  a  loop,  it  must 
hold  upon  entering  the  loop,  and  assuming  that  It  held  before  executing  the  loop  body,  then 
it  must  hold  after.  For  a  relation  to  be  an  invariant  purpose  of  a  loop,  it  must  be  the  goal 
upon  entering  the  loop,  and  assuming  that  It  is  the  goal  before  executing  the  loop  body, 
then  it  must  be  the  goal  after. 

The  loop-body  statement 

approach  j«0  varying  s,t 

expresses  the  desire  to  make  definite  progress  towards  the  goal  j=0  with  each  loop 
Iteration.  Since  i  is  set  to  the  nonnegative  integer  a  before  entering  the  loop,  it  follows 
that  the  loop  decreases  the  value  of  s  .  Thus,  we  can  ensure  loop  termination  by 
monotonicaily  decreasing  the  integer  i  ,  while  s  remains  nonnegative;  the  loop-body 
subgoal,  then,  Is 

achieve  jcN,  sis'  varying  s,t  , 
where  s'  denotes  the  value  of  s  prior  to  this  statement. 

The  other  conjunct  of  the  subgoai  feN+1  Is  true  upon  entering  the  loop,  when 
f~bc!4+l  ,  and  must  be  kept  true  by  the  loop.  Within  the  loop,  we  also  wish  to  protect  the 
invariant  assertion  gcd(s,t)=ged(a,b)  and  invariant  purpose  z=gcd(s,t).  If 
gcd(s',t')=gcd(a,b )  holds  for  the  prior  values  of  s  and  f ,  then  gcd(s,t)*gcd(a,b)  will  hold 
for  the  new  values,  provided  that  gcd(s,0‘gcd{s',l') .  This  relation  also  maintains  the  goal 
z*gcd(s,t)  :  If  gcd[s,  t)*gcd{s',  t')  and  the  goal  z*gcd(s,()  can  be  achieved,  then 
z*gcd(s',  t')  will  be  achieved  as  well.  The  complete  loop-body  subgoal  Is 

achieve  rcW,  s<s\  feN+J,  gcd(s,  t)=gcd(s',  t')  varying  s,t  . 

Matching  the  information  about  the  domain  expressed  in  the 

fact  gcdir«m(u,v),v)*gcd(v,u )  when  ueN,  i/cN+l 


with  the  conjunct  gcd(s,t)=gcd(s',t')  suggests  letting  to'  and  s-remU'.s') ,  leaving  the 
goal 

achieve  jeN,  s<s\  reN+l,  f=i',  s=rem(t', s'),  f'eN  varying  s,t  . 

Since  r=rrm(f',f')  and 

fact  rem{u,v)<v,  rem(u,v)e N  when  ueN,  veN+1  , 

the  conjuncts  ieN  and  s<s'  hold,  provided  that  f'eN  and  i'eM+1  .  Recall  that  we  are 
assuming  that  the  invariants  f'cN+1  and  i'eN  are  true.  For  the  loop-body  to  be 
executed,  the  exit  test  s= 0  must  have  been  false,  i.e.  i'*0  ;  therefore,  .  Finally, 

we  are  left  with  the  goal 

achieve  t-s',  s-rem{i',t')  varying  s,t  . 

suggesting  the  multiple  assignment 

(s,t)  :*  (rem(s,t),s)  . 


Since  for  each  step  in  the  construction,  achieving  the  new  subgoals  satisfies  the 
previous  goal,  the  final  program, 

I - 1 

|  Po:  begin  comment  gcd  program  j 

|  assert  a*0S/b*0  | 

|  purpose  z=gcd(a,b )  | 

j  purpose  gcd{s,t)=gcd(a,b)  | 

|  (s,t)  :=  (a,  b)  \ 

|  assert  gcd{s,t)=gcd{a,b )  | 

|  -loop  assert  gcd[s,t)-gcd[a,b )  j 

\  purpose  z=gcd(s,t)  j 

j  until  r=0  j 

j  ( s,t )  :«  (rem(s,t),s)  | 

|  repeat  | 

I  z  :■  t  j 

|  assert  z*gcd{a,b)  | 

1  end  ,  | 

l _ l 

la  guaranteed  to  achieve  the  initial  specifications 
assert  a.fteIN 

achieve  z*gcd{a,b)  varying  z  . 

In  the  next  section,  we  formalize  our  program-synthesis  strategies. 
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a.  STRATEGIES 

In  this  section  we  present  some  programming  strategies;  each  transforms  a  given  goal 
Into  code  containing  simpler  subgoals. 


I.  Strengthening  Rule 

The  strengthening  rule  Is  used  to  replace  a  goal  by  another  sufficient  goal: 

achieve  a(u)  varying  u 

fact  q(u)  when  <9(u) _ 

purpose  a(u) 

achieve  0(u)  varying  u 
assert  a(u)  , 

This  rule  states  that  if  It  is  known  that  achieving  0  will  imply  that  the  desired  relation  a 
holds,  then  replace  the  goal 

achieve  a(u)  varying  u 

with  the  "stronger",  but  presumably  simpler,  subgoal 

achieve  0 (u)  varying  u  . 

For  example,  the  goal 

achieve  z=gcd(x,  y)  varying  x.y.z 

may  be  strengthened  to 

achieve  x=0,  z=y  varying  x,y,z  , 

since  the 

fact  gcd(0,u)=u 

tells  us  that  z=gcd(x,y)  when  x=0  and  z-y . 

The  goal  0  may  also  Introduce  new  variables  v  ,  yielding 
achieve  0(u,v)  varying  u,  <7  . 

The  values  of  the  new  program  variables  are  set  by  the  code  generated  from  this  subgoal, 
but  0  must  Imply  a  for  any  values  of  v .  Note  that  this  means  that  0  need  only  be 
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achieved  for  some  values  of  v  ;  their  final  values  are  unimportant  as  they  are  not  output 
variables.  Some  generally  useful  transformations  of  this  sort  are  expressed  by  the 
following  facts: 

fact  p(u)  when  p(v),  p(v)op(u)  , 

fact  p(u)  whan  p(v),  u*v  , 

fact  p(f(u))  whan  p(f(v)),  /(«)«/(»)  , 

and 

fact  pifdu))  whan  p(v),  v*f(u)  . 

For  example,  the  goal 

achieve  z=gcd(a,b)  varying  z 
may  be  transformed  into 

achieve  z=gcd(s,t),  ( s,t)*(a,b )  varying  z,s,t  . 

or  to 

achieve  z*gcd(s<t),  gcd{s,t)»gcd{a,b )  varying  z,s,t 
In  any  case,  z=gcd{a,  b)  is  Implied  for  any  values  of  t  and  t . 

A  special  case  of  this  rule  is  the  replacement  of  a  goal  by  a  logically  equivalent,  but 
simpler,  goal.  For  example 

achieve  x*=0,  x*y  varying  x,y 

may  be  replaced  by  the  equivalent 

achieve  x*0,  y*0  varying  x,y  . 


2.  Assignment  Rule 

Assignment  statements  are  formed  by  the  following  rule 

achieve  y,=/,(x),  y ,«/,(x) . V/,,(*)  varying  yt.y. . 

purpose  v/.(*)-  *»■/.<*>•  •  •  •  » 

. 7„)  . /*<*» 

assert  y */,(x),  yrffi) . V/,(*)  . 


i 


*'  * 
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where  the  variables  yt,yt . yn  do  not  appear  in  x,  and  /,./,.  ...,/„  are 

composed  of  only  primitive  operations.  For  example,  the  goal 

achieve  x-0,  yO  varying  x,y 
may  be  achieved  by 

<x,j)  (0,0)  . 

This  rule  suggests  that  one  first  attempt  to  isolate  variables  on  one  side  of  an  equality, 
e.g.  a  goal  of  the  form 

achieve  g(y)*f(x)  varying  y 

should  be  transformed  into 

achieve  y*g~(/W)  varying  y  , 
where .  g~  Is  the  inverse  (assuming  that  it  exists)  of  the  function  g  . 


S.  Conditional  Rult 

Conditional  statements  are  formed  in  the  following  manner: 
purpose  a(5) 

achieve  0(5),  7(5)  varying  5 _ 

purpose  a(5) 

if  0(5)  then  achieve  7(5)  protecting  0(5)  varying  5 
else  assert  -0(5) 

achieve  at(5)  varying  5 
fi  , 


provided  that  the  relation  0  is  computable,  i.e.  when  0  is  composed  of  primitive 
functions  and  predicates.  In  other  words,  one  way  of  achieving  0  is  to  test  if  it  holds: 
when  It  does,  protect  that  relation  while  achieving  the  remainder;  when  It  does  not  hold, 
try  to  use  that  fact  while  achieving  the  original  goal. 

For  example,  to  solve  the  conjunctive  goal 

purpose  t»ged(x,y) 

achieve  x-0,  x*y  varying  t  , 

we  may  test  if  one  conjunct  already  holds: 


i 


- 

J  ■ 


i  . .  !£*-•  .  .*  *' 
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purpose  z*ged(x,y) 

if  *»0  than  achieve  z*y  varying  t 
•1m  assart  x*Q 

achiava  z*gcd(x,y )  varying  t 

ti  . 


4.  S putting  Strategies 

Suppose  we  have  a  conjunctive  goal  of  the  form 
achieve  0(5),  7(5,5)  varying  5,5  , 

the  u  variables  appearing  only  In  7  .  We  would  like  to  split  this  goal  into  two 
consecutive  subgoals,  first  achieving  0  and  then  7  : 

purpose  0(5),  7(5,  5) 

achieve  0(5)  varying  5 
achieve  7(5,  5)  varying  5,5 
assart  0(d),  7(5,5)  . 

Unfortunately,  things  are  not  as  simple  as  that.  As  pointed  out  earlier,  the  problem  is  that 
in  achieving  the  second  goal  7  ,  we  may  unwittingly  destroy  the  relationship  0  that  has 
already  been,  achieved.  We  must,  therefore,  somehow  maintain  0  while  achieving  7  .  We 
consider  three  "protection"  strategies  for  achieving  the  second  subgoal,  7  ,  while 
protecting  the  first,  0  ,  from  being  undone. 


*  Disjoint  Goal  Rule.  If  in  achieving  the  second  subgoal  7,  the  value  of  5  need  not 
be  set,  then  clearly  the  two  subgoals  are  independent.  We  have  then  the  consecutive 
goals 


achieve  0(5),  7(5,5)  varying  5,5 
purpose  0(5),  7(5,5) 

achieve  0(5)  varying  5 
achieve  7(5,5)  varying  5 
assert  0(5),  7(5,5)  . 


For  example,  the  two  conjuncts  of  the  goal 
achieve  x>0,  z*y  varying  x,y,  z 
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contain  different  variables.  We  can  therefore  split  it  Into 

purpose  x*0,  z=y 

achieve  x*0  varying  x 
achieve  varying  j,i 
assert  x*0,  z-y  . 


•  Protection  Rule.  Another  strategy  is  to  Insist  that  after  each  stage  executed  in 
achieving  Y  ,  0  remains  true  for  the  current  values  of  the  variables: 

achieve  0(5),  Y(u,  v)  varying  u,o 
purpose  0(d),  Y(u,  U) 

achieve  0(5)  varying  o 
achieve  7(u, »)  protecting  0(v)  varying  u,  v 
assert  0(5),  7(5,?)  . 

One  way  to  protect  a  relation  is  to  insist  that  its  variables  do  not  change  value,  i.e.  5=5’  , 
as  in  the  disjoint  goal  rul*  above;  another  method  Is  the  formation  of  a  loop,  with  the 
protected  relation  serving  as  the  invariant  assertion,  as  we  shall  see. 

For  example, 

achieve  z=gcd(s,t),  gcd(s,t)=gcd(a,b)  varying  z.s,  t 
may  be  broken  into 

achieve  gcd(s,t)=gcd(a,b)  varying  s,t 

achieve  z*g<d(s,t)  protecting  gcd(s,t)*gcd(a,b)  varying  z.s.t  . 


•  Preservation  Rule.  Assume  that  the  program  variables  5  are  not  output  variables, 
rather  they  were  introduced  to  facilitate  achieving  aome  purpose  a(u) .  Then  the  final 
values  of  5  are  unimportant,  and  one  need  only  achieve  0  and  7  for  some  arbitrary 
values  of  5  .  As  we  saw,  the  prottetim  rul t  achieves  both  0  and  7  for  the  final  values 
of  v  ;  while  In  the  disjoint  rult,  the  values  of  v  are  the  same  after  achieving  7  as  after 
achieving  0  .  A  third  possibility  is  that  after  achieving  0  for  some  v  ,  one  achieve  7  for 
those  same  values  of  p  though  the  current  value  of  v  may  be  changed  in  the  process. 
The  only  requirement  is  that  achieving  7  for  the  new  values  of  v  also  implies  7  for  the 
previous  values  of  v  .  (Equivalently,  If  7  was  the  goal  for  the  old  v  ,  then  7  remains 
the  goal  after  this  stage  —  for  the  new  p .)  Thus,  by  achieving  7  ,  we  end  up  with  0  and 
7  holding  for  the  old  values  of  » . 
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The  rule  is 

purpose  a(u) 

achieve  (9(5),  7(5,5)  varying  5,? _ 

purpose  a  (5) 

achieve  0(v)  varying  5 

achieve  7(5,5)  preserving  7(5,5)  for  5  varying  5,5 
assert  a (5)  . 

The  second  goal  7  may  then  be  transformed  further.  In  particular,  this  rule  can  lead  to  a 
loop,  with  the  preserved  relation  serving  as  the  invariant  purpose  of  the  loop.  We  require 
that  7  remain  the  goal  for  current  values  of  the  variables  throughout  the  achievement  of 
7  itself. 

For  example, 

achieve  z*gcd(s, t),  a,b)  varying  t,s,t 

may  be  broken  Into 

achieve  (s,t)*(a,b)  varying  s,t 

achieve  z=gcd{s,t )  preserving  t*gcd{s,t )  for  s,t  varying  z,s,t  . 

The  second  subgoal  may  then  be  strengthened  to 

achieve  r=0,  z-t  preserving  z*gcd(s,t)  for  s,t  varying  z,s,t  . 

To  summarize  the  difference  between  the  last  two  rules,  we  may  say  that  the 
protection  rule  applies  to  goals  already  achieved,  while  the  preservation  rule  applies  to  goals  to 
be  achieved. 


5.  Loop  Rules 

The  loop  rules  allow  a  given  goal  to  be  achieved  step  by  step.  We  present  two  rules 
for  forming  Iterative  loops  and  a  rule  for  guaranteeing  their  termination.  We  also  Include  a 
recursion-formation  rule. 
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•  Forward  Iterative  Loop  Rule.  Given  a  goal  of  tha  form 
achieve  &  protecting  a  varying  u 

(preceding  code  has  achieved  a  and  we  wish  to  keep  o  true  while  achieving  0  ),  the 
following  rule  will  generate  an  iterative  loop: 

achieve  0(u)  protecting  a(u)  varying  u _ 

purpose  0(u),  a(u) 

loop  assert  a(u) 
until  0(u) 

approach  0(u)  protecting  a(u)  varying  u 
repeat 

assert  0(5),  a(u) 

This  is  permissible  provided  the  exit  test  0  is  primitive. 

The  statement 
assert  a(u) 

is  the  invariant  assertion  of  the  loop  stating  that  a  is  true  whenever  execution  reaches 
the  beginning  of  the  loop.  It  is  invariant,  since  it  is  given  that  a  is  true  when  the  loop  is 
first  entered  (and  only  needs  to  be  protected),  and  the  loop-body  subgoal 

approach  0(5 )  protecting  a(5)  varying  5 

will  ensure  that  a  remains  true  after  each  Iteration.  The  loop  will  terminate  when  the  exit 
condition  0  becomes  true;  at  that  point  both  the  invariant  a  and  the  test  0  must  hold. 
In  order  to  guarantee  that  loop  execution  will  Indeed  terminate,  we  must  make  definite 
progress  towards  0  \  this  is  the  meaning  of  "approach". 

For  example,  the  goal 

achieve  j«0  protecting  gcdU,thgcd(a,b)  varying  r,i,f 
euggests  the  loop 

purpose  t" 0,  gcd(s,  t)*gcd{a,  b) 
loop  assert  gcd(s,ty*gcd{a,b) 
until  j«0 

approach  *«0  protecting  fcrf(M)"fcrf(«,t)  varying  i,f 
repeat 

assert  *«0,  gcd(s,t)*gcd(a,b)  . 

The  new  goal 


t  h 


* 


approach  j=0 


can  be  achieved  by  decreasing  the  value  of  s ,  provided  that  s  was  nonnegative  upon 
loop  entry.  The  invariant  must  be  protected  in  the  process. 


•  Backward  Iterative  Loop  Rule.  For  the  case  where  we  wish  to  achieve  a  relation  0 
while  preserving  an  ultimate  goal  a  ,  we  have 

achieve  0(u,  v)  preserving  a(u,v)  for  v  varying  u,  v 
purpose  0{u,v) 

loop  purpose  a(u,  v) 
until  0(u,  v ) 

approach  0(u,  v)  preserving  a(u,v)  for  v  varying  u,  v 
repeat 

assert  0(u,v)  . 

As  with  the  forward  loop,  this  Is  permissible  only  If  0  is  computable. 

The  purpose  of  the  loop  is  to  achieve  the  exit  relation  0  while  preserving  the 
ultimate  purpose  a  .  The  loop  will  terminate  when  the  exit  condition  0  becomes  true;  at 
that  point,  the  fact  that  0  holds  may  be  used  to  help  achieve  the  purpose  a  .  The 
statement 

purpose  a(u,  v) 

contains  the  invariant  purpose  of  the  loop  and  states  that  whenever  execution  reaches 
the  beginning  of  the  loop,  what  remains  to  be  computed  Is  o  ,  for  the  current  values  of  the 
variables  u  and  v  .  Upon  exiting  the  loop,  the  goal  Is  o  ,  and  a  is  the  goal  whenever 
the  loop-body  subgoal 

approach  0(u,  v)  preserving  a(u,v)  for  v  varying  u,» 

Is  executed. 

For  example,  the  goal 

achieve  j>0,  z*t  preserving  tmgcd{s,  0  for  s,t  varying  x,s,t  , 
may  be  split  Into  disjoint  goals 

achieve  j-0  preserving  xmgcd(i,  t)  for  t,t  varying  r.r 
assert  j>0 
purpose  *■/ 

achieve  z*t  preserving  fgedU.t)  for  M  varying  z  . 
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By  assigning  x:»t ,  the  subgoal  z*t  Is  acNsvsd  as  Is  ths  preserved  goal  x»ged{s,  r) ,  since 
i* 0.  Letting  a  be  z*gcd(s,t)  and  0  be  1*0 ,  the  remaining  subgoal 

achieve  i«0  preserving  z*gcdU,  t)  for  t,t  varying  s,t 

may  be  transformed  Into  the  loop 

purpose  i*0 

loop  purpose  z*gcd(s,t) 
until  t*0 

approach  i*0  preserving  z»ged{s,t)  tor  s,t  varying  s,  t 
repeat 
assert  1*0  . 

Within  the  loop,  the  purpose  z*gcd(s,t)  must  be  maintained  while  making  progress  towards 

i*0 . 


•  Termination  Rule.  Assume  that  we  are  given  a  loop-body  subgoal 

approach  0(5)  protecting  o(5)  varying  5  . 

Clearly  in  order  to  make  progress  towards  0  ,  one  of  the  variables  5  must  be  changed. 
I.e.  5*5'.  This  Is  not  however  sufficient  to  ensure  that  0  will  ever  be  attained.  What 
we  need  is  the  notion  of  well-founded  set:  a  wtU-foundtd  set  (IV.  >)  consists  of  a  set  of 
elements  W  and  an  ordering  >  defined  on  the  elements,  such  that  there  can  be  no 
infinite  descending  sequences  of  elements  W|>a»2>...  •  So,  if  throughout  execution  of  the 

loop  we  keep  5eW  ,  for  some  well-founded  set  [W, »  ,  and  insist  that  with  each  iteration 
5  is  reduced  In  that  ordering,  i.e.  u'>5  ,  then  termination  is  guaranteed.  In  particular,  we 
must  have  u^u*  ,  where  u„  denotes  the  value  of  5  upon  entering  the  loop  and  5* 
denotes  the  value  upon  exiting.  (To  determine  this,  we  may  use  whatever  facts  are  known 
about  5,  and  5*  ,  e.g.  a(5#) ,  a  (5*) ,  end  0(5*) .) 

We  have,  for  forward  loops,  the  termination  rule 

assert  u„,  u„elV,  5„>u* 

approach  0(5)  protecting  a(u)  varying  5 _ 

assert  -i0(5) 

achieve  u'> 5  protecting  a(u),  uzW  varying  5 


and  similarly  for  backward  loops 


«5fc 

4Lr 
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uurt  U'.UgCW,  u#>u# 

approach  0(5)  pnwrvifll  a(5)  for  ?  varying  5 
assart  -£(5) 

achiava  «'>u  preserving  a(u),  ucW  for  »  varying  u  , 
where  (W,  >)  is  some  well-founded  set. 

The  well-founded  set  most  commonly  used  for  termination  proofs  is  the  set  N  of 
nonnegative  integers  under  the  >  ordering.  When  dealing  with  more  than  one  variable, 
the  lexicographic  ordering  on  n-tuples  is  useful.  For  example,  to  use  the  lexicographic 
ordering  for  two  variables  u  and  v ,  we  first  look  for  well-founded  sets  W%  and  W. 
such  that  ueW,  and  veWt .  Then  we  consider  the  pair  (u,  v)  and  require 

achieve  (u\  v’)>(u,  v)  protecting  a(u,v),  ucIV,,  veW}  varying  u,v  . 

Where  >  is  the  lexicographic  ordering  on  pairs,  l.e.  we  must 

achieve  u’>uV(u'*u/\v'>v)  protecting  a(u,v),  ncW,,  veWt 

varying  u.v  . 

Another,  often  useful,  way  of  handling  several  variables  is  based  on  an  assumption  of 
monotonicity  for  each  variable.  Determining,  for  some  variable  u  ,  that  the  initial  value  u„ 

is  greater  than  the  final  value  u*  suggests  that  u  decrease  monotonically,  i.e.  u'>u  .  in 
that  case,  we  may  also 

assert  uo>u>uA 

within  the  loop  (provided  we  can  determine  the  values  of  «t#  and  ).  Given  two 
monotonic  variables  u  and  o  ,  termination  may  be  ensured  by  requiring 

achieve  u'Vu,  »'>«,  «'>uV v'>v 

protecting  a(u,v),  ue (V|t  V€W„  u>u#,  v>vm  varying  u,,o 


In  other  words,  each  iteration  reduces  the  value  of  one  of  the  variables,  without  increasing 
any  other  (cf.  the  multiset  ordering  on  fu,*}  in  Dershowitz  and  Manna  [Mar.  1978]). 
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•  Recursive  Loop  Rule.  The  following  rule  forms  e  recursive  loop: 

assert  e(u),  ucW 
purpose  a(u) 

assert  v(v),  veW ,  u>v 
achieve  a(v)  varying  v 

assert  a(u ) _ 

assert  v>(u),  ueW 

P(u):  begin  purpose  a(u) 

assert  ?(v),  veW,  u>v 
purpose  a( v) 

P(v) 
assert  a(«) 

end 

assert  a(u)  . 

The  current  goal  is 

achieve  a(v)  varying  v  , 

while  the  code  that  is  being  synthesized  —  call  It  P  —  has  the  similar 
purpose  or(u) ' . 

Before  we  can  insert  a  recursive  call  P(o) ,  we  must  know  that  the  input  assertion  is 
satisfied  by  the  arguments  v .  Furthermore,  to  guarantee  that  the  recursion  will  not 
continue  forever,  we  require  u>o  In  some  well-founded  ordering  (IV,  »  . 

Conditional-formation  techniques  are  the  subject  of  Luckham  and  Buchanan  [1974] 
and  Warren  [1976].  The  achievement  of  conjunctive  goals  Is  the  topic  of  Waldinger 
[1977];  protection  mechanisms  ars  used  for  this  purpose  by  Sussmsn  [1976];  Sacerdoti 
[T976]  addresses  their  nonlinear  nature.  The  use  of  Invariants  for  the  automatic 
construction  of  iterative  loops  is  also  discussed  by  Duran  [1976].  Recursion-formation 
techniques  are  discussed  in  detail  by  Manna  and  Waldinger  [1977];  similar  work  appears  in 
Siklossy  [1974]  and  Darlington  [1976].  Misra  [1976]  gives  criteria  for  a  loop  to  be 
formed  directly  from  the  specifications. 

In  the  next  section,  we  apply  these  rules  to  the  synthesis  of  several  programs. 
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4.  EXAMPLES 

Our  first  example  is  a  straightforward  synthesis  of  the  integer  square-root  function. 
Arrays  are  introduced  in  the  second  example,  which  is  a  program  to  find  the  position  of  a 
minimal  element  of  an  array.  Our  concluding  example  Is  Hoare's  Partition  algorithm  [1961]; 
it  is  a  nontrivial  problem,  requiring  some  degree  of  understanding  and  ingenuity  to  program. 


Example  1;  Integer  Square-root. 

In  an  earlier  chapter  we  developed  a  binary  Integer  square-root  program  from  a 
schema;  In  this  chapter  our  goal  is  to  synthesize  some  program  satisfying  the 
specifications 

I - 1 

|  Pt:  begin  comment  Integer  square-root  program  | 

|  assert  aeN  | 

j  achieve  z=[Va}  varying  z  | 

j  end  I 


from  scratch.  The  program  should  set  the  variable  z  to  the  largest  integer  not  greater 
than  the  square-root  of  a  ,  for  any  nonnegative  integer  a  . 

We  assume  that  the  V  function  is  riot  primitive;  oxherwlse  we  could  achieve  our 
goal  using  the  assignment  rule  to  obtain 

z  :«  LV«J  . 

Therefore,  as  a  first  step,  we  endeavor  to  replace  the  goal  with  one  that  does  not  contain 
t**e  V  function. 

Using  the  definition  of  [u J  , 

fact  v*(uj  a  0SuAu<t>+lAscZ  , 

the  goal 

achieve  z>[vTj  varying  z 


may  be  transformed  into  the  equivalent  goal 
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purpose  z«[VSJ 

achieve  zSVa,  Va<z+1,  zeZ  varying  z 
assert  z-[Vaj  . 

Using  the 

fact  uSViT  m  tfiiv  when  ufcO 

to  eliminate  the  V~  operator,  the  conjunct  z£-Ja  may  be  replaced  by  z2Sa  and  Va<z+ 1 
may  be  replaced  by  a<(z*l)2  ,  with  the  side  conditions  ziO  and  z*l£0  added: 

achieve  z2Sa,  zfc 0,  a<(z+l)2,  z+l£0,  zeZ  varying  z  . 

This  simplifies  to  just 

achieve  z2<a,  a<(z+]  )2,  ztW  varying  z  . 

The  above  subgoal  is  a  conjunction  of  three  relations;  the  protection  rule  suggests 
splitting  it  into  two  consecutive  subgoals: 

purpose  z2<a,  a<(z+l)2,  zcN  varying  z 
achieve  a<(z+l)2,  zeN  varying  z 
achieve  z2<a  protecting  a<(z+l)2,  zcN  varying  z 
assert  z2Sa,  a<(z+l)2,  zeN  varying  z  . 

Later,  we  shall  see  what  alternative  splittings  might  result  in. 

To  achieve  the  first  subgoal 

achieve  a<(z+l)2,  zeN  varying  z 

we  apply  the  strengthening  rule  to  this  subgoal,  using  the  transitivity  of  inequality 
expressed  in  the 

fact  uiw  when  vui,  v<w  , 

obtaining  the  stronger 

achieve  a<v,  v£(z+l)2,  zeW  varying  t,v  ; 

Now,  the 


fact  uSu2  when  u^lVuSO 
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tells  us  that  taking  z* 1  for  v  will  give  vS(z* ,  provided  that  z+l£l  Vz+lsO .  The 
subgoal  zeM  Implies  z*  1  fcl  ,  leaving 

achieve  a<z+l,  zeN  varying  z  . 

Since  v  is  not  an  output  variable,  It  has  been  eliminated  from  the  goal.  The  goal  may  be 
strengthened  further  to 

achieve  a-z  varying  z, 

by  matching  It  with  the 

fact  u<u*v  when  vX)  . 

This  goal,  in  turn,  may  be  attained  by  the  simple  assignment 

purpose  a<(z+l',2,  zeN 
z  a 
assert  z=a  . 


The  forward  loop  rule  suggests  turning  the  second  subgoal 

achieve  z2Sa  protecting  a«z+l)2,  zeN  varying  z 
into  a  loop  with  the  Invariant 

assert  a<(z+i)2,  zeN 
maintained  true  until  the  exit  clause 
until  z^sa 

becomes  true.  We  have  the  skeleton  of  a  loop: 

purpose  a<(z+l)2,  zeN 
z  >  0 

assert  z«« 

purpose  z^Sa,  a<(z+ 1)^,  zeN 
loop  assert  a<(z«|)2,  zeN 
until  z^So 

approach  z^sa  protecting  «<(z*l)2,  zeN  varying  z 
repeat 

assert  z^ia,  a<(z+ 1)2,  zeN  . 
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Within  the  loop  body,  we  must 

approach  z2S«  protecting  s<(i*l)2,  zcti  varying  z 
in  order  to  make  progress  towards  the  exit  test,  while  protecting  the  invariants. 

To  ensure  termination  of  this  loop,  the  ttmlnatim  rult  requires  that  the  nonnegative 
integer  z  be  reduced  in  some  well-founded  ordering.  We  note  that  upon  exit  i^Sa  , 

while  upon  entering  the  loop  z,*e  .  Therefore,  z„Sz,2Sz, ,  and  we  hypothesize  that  z  is 
decreasing  monotonically  from  s  to  it  final  value.  We  therefore  take  the  set  of 
nonnegative  integers  N  under  the  usual  >  ordering  as  the  well-founded  set.  We  have 
obtained  the  loop-body  subgoal 

assert  «<z2 

achieve  z'>z  protecting  «<(z*l)2,  zcN  varying  z  , 
i.e.  we  wish  to  set  the  nonnegative  integer  z  to  a  value  less  than  its  current  one,  while 

protecting  the  loop  invariant  a<(z+l)2  .  The  assertion  indicates  that  the  exit  test  z2Sa 
does  not  yet  hold  if  the  loop  is  being  continued. 

With  each  loop  iteration  we  wish  to  decrease  the  value  of  z  ,  while  protecting  the 
invariant  a<(z*l)2  .  Using  the  transitivity  of  inequality  again,  suggests  looking  for  some  v 
such  that  a<v  and  vS(z+l)2  .  But  a <z'2  may  be  asserted  for  the  previous  value  of  z  ; 

therefore,  to  achieve  a<(z*1)2 ,  we  need  only  achieve  z'2S<z*l)2  ,  I.e.  z'Sz+l  .  This 
leaves  us  with  the  goal 

achieve  z'>z,  z'Sz+1  protecting  zcN  varying  z 
which  Is  equivalent  to 

achieve  z*z'-l  varying  z 
and  may  be  achieved  by  the  assignment 
z  :«  z-1  . 

We  have  derived  the  program 


i 
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j  Pt:  btfln  comment  an  integer  squat* -root  program j 

|  assert  aeM  | 

j  x  :*  a  | 

|  loop  assert  a<(z+l)2,  zeM  | 

|  until  z^sa  [ 

j  z  :*  z-1  | 

j  repeat  j 

|  assert  z»[VaJ  j 

|  end  .  | 

I - - J 

With  most  of  the  subgoals  left  in,  the  program  would  look  like: 

f - - - - 

|  Pt:  begin  comment  a  cluttered  integtr  square-root  program 

|  assert  aeM 

|  purpose  z=|.VaJ 

|  purpose  ziVa,  Va<z* I,  zeZ 

J  purpose  z^ia,  a<(z+l)2,  zeM 

|  purpose  a«z*l)2,  *cM 

|  z  :»  a 

|  assert  z=a 

|  purpose  z%£a,  a<(z+ 1)^,  zeM 

|  loop  assert  e<(z«l)2,  zeM 

|  until  z2Sa 

|  purpose  z'>z,  o<(z+I)2,  zeM 

|  purpose  z’>z,  z'sz* I,  zeM 

|  z  :■  z-l 

j  assert  z/>z,  z'Sz+1,  zeM 

|  assert  z'>z,  a<(z+lfi,  zeM 

j  repeat 

|  assert  z^sa,  a<(z+l)2,  zeM 

|  assert  z^Sa,  c<(z*l)2,  zeM 

|  assert  ziVa,  Va<z*l,  zeZ 

|  assert  z«{.V<*J 

end  . 
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What  would  have  happened  had  we  split  the  goal 

achieve  z^ia,  a<(z*l)2,  zeN  varyinf  z 
In  a  different  manner?  Had  we  choaen  to  first 

achieve  z^Za,  zeN  varyinf  z 

and  then 

achieve  «<(z+l)2  protecting  z^Sa,  zeN  varyinf  z  , 
we  would  be  led  in  a  similar  manner  to  the  loop  skeleton 

achieve  z^ia,  zeN  varyinf  z 
purpose  z%£a,  a<(z*  1)2,  zeN 
loop  assert  z^Ss,  zeN 
until  a<(z+I)2 

approach  «<(z+l)2  protecting  z^ia,  zeN  varying  z 
repeat 

assert  z^Sa,  a<(z+l)2,  zeN  . 

To  achieve  the  Initialization  subgoal,  we  note  that  the  Input  assertion  aeN  implies  afcO  . 
Therefore,  to  achieve  z*<-a  ,  It  suffices  for  z^iO  .  But  the 

fact  Oiifi 

implies  that  z^*0  ,  so  we  may  Initialize  z:*0  .  We  would  then  decide  to  approach  the  exit 
test  by  increasing  z  from  0  .  To  guarantee  termination,  we  could  use  the  well-founded  set 
of  integers  less  than  Va  ;  the  smaller  the  integer,  the  greater  it  Is  in  the  well-founded 
ordering.  Continuing  in  a  manner  paralleling  the  derivation  of  Pt ,  we  get 


I  I 

|  P'l  begin  comment  cUttrnativ *  inttger  s  quart -root  program  | 

|  assert  acN  j 

I  *  :»  0  j 

|  loop  z2Sa,  zcN  | 

|  until  «<(z+l)2  | 

j  z  :■  z*  1  j 

|  repeat  | 

|  assert  z-[VaJ  J 

|  end  .  | 

i  * 

In  the  section  on  extension,  we  shall  see  how  this  program  may  be  improved. 
Had  we  split  the  goal 

achieve  zSVa,  VaKz+l,  zcN  varying  z 

into 

achieve  zcN  varying  z 

achieve  z2sa,  a<(z*l)2  protecting  zeM  varying  z  , 
we  would  be  led  to 

assert  ccN 

achieve  zeM  varying  z 
loop  assert  zcN 

until  z^SaAaCfz^l)2 

approach  z2SaAa<(z*i)2  protecting  zcN  varying  z 
repeat 

assert  z«[VoJ  . 


The  choice  of  Initial  value  for  z  such  that  zcN  is  completely  arbitrary;  to  ensure 
termination  we  would  have  to  first  determine  whether  the  chosen  Initial  value  Is  less  or 
greater  than  the  desired  final  value. 


Ml. .vjh:  i mmcv,, 


T-,  . 
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The  resulting  program  would  be 

assert  asN 
z  :e  N 

loop  assert  tcN 

until  z2&Aa<(z+i)2 

if  z*4a  then  z  :■  z+l 
repeat 

assert  z*[VaJ  , 


z  :*  z-l  fi 


where  ziaN  is  a  nondeterministic  assignment  of  some  element  of  the  set  N  to  the 
variable  z  .  This  solution  is  more  complicated  than  either  of  the  previous  two  possibilities. 
In  general,  it  is  advisable  to  maintain  invariant  as  much  of  the  goal  as  possible  and  keep 
the  exit  test  as  simple  as  possible. 


Example  2:  Array  Minimum. 

In  this  example,  we  wish  to  synthesize  a  program  to  search  for  the  position  of  a 
minimal  element  In  an  array  segment.  Our  goal  is  to  synthesize  a  program  for 

r~ — - — i 

|-Pts  begin  comment  array  minimum-position  program  j 

|  assert  l.jeN,  t<j  | 

|  achieve  A[z]$A[i:J],  iSzij  varying  z  | 

|  end  .  | 

«  i 

The  conjunct  A[z}SA[l:J]  Is  short  for  (Vf )(i£f£J)g[z]3^[f]  ;  In  general,  for  any  predicate 
P  .  p[u\v ]  is  short  for  (VfHuSfSv)p(f)  .  Note  that  the  array  A  Is  constant  and  only  the 
value  of  the  variable  z  may  be  altered  by  the  program.  In  other  words,  we  wish  to  set 
the  variable  z  to  the  Index  of  an  occurrence  of  the  smallest  element  in  the  nonempty 
array  segment  A[i:j] . 

Using  the 

fact  p(u)  when  p(o),  u*o  , 

this  goal  may  be  strengthened  by  Introducing  a  new  program  variable  y  and  substituting  It 
for  the  constant  i  s  the  conjunct  yi  must  be  added  to  the  goal.  Introducing  a  new 
variable  will  allow  the  program  to  manipulate  its  value  so  that  the  goal  may  be  achieved  in 
stages.  We  derive 


L 
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purpose  A[z]*A[i:j],  iiiij 

achieve  A[z)<A[y:j],  ySzSj,  y*i  varying  z,y 
assert  A[zjSA[i:j],  iizij  . 

Using  the  protection  rule,  we  shall  attempt  to  achieve  this  goal  in  two  stages,  first 
achieving  both  and  yizZ]  and  then  achieving  y-i : 

achieve  A[z]iA[y:j],  ySzSJ  varying  z.y 

achieve  y*i  protecting  A[z]SA[y:j],  y&z&j  varying  z.y  . 

By  matching  the  first  goal 

achieve  Alz]4A[y:j],  yizij  varying  z.y 

with  the 

fact  p[u:u ]  when  p(u)  , 
the  goal  may  be  strengthened  to 

achieve  A[z]iA[j],  y*j,  yizij  varying  z.y  . 

Using  reflexlvity 

fact  uiu 

to  further  strengthen  this  goal,  we  get 

achieve  A[z]-A[j],  yj,  yizij  varying  z.y  . 

Now  the 

fact  /(u)*/(i>)  when  u*v  , 

for  any  function  /  (the  array  A  may  be  considered  a  function),  suggests 
achieve  z*j,  y*J  varying  t.y  . 

This  is  in  turn  achievable  by  the  multiple  assignment 
(z.y)  :•  (J.j) 

We  are  left  with  the  subgoal 

achieve  y*l  protecting  A[z]iA[y:j),  ySzij  varying  z.y  , 
which,  by  the  forward-loop  rule,  suggests  the  Iterative  loop 
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loop  assort  A[z]£A[y:j],  y&zij 
until  y*i 

approach  y*l  protactins  yizij  varying  z,y 

repeat 

assert  A[x]iA[y:J},  yizij,  yt  . 

The  remaining  loop-body  subgoal  is 

approach  y*i  protecting  A[z]£A[y:j],  ySz ij  varying  z,y  . 

By  noting  that  upon  entering  the  loop  j t*j  and  upon  exiting  the  loop  yt*i ,  where  It  is 
given  that  i£J  ,  the  termination  ruit  suggests  that  the  variable  y  remain  an  Integer  and 
decrease  monotonlcally  from  j  to  i .  Including  the  range  of  y  ,  we  now  have 

assert  y*l 

achieve  y">y  protecting  A[z}SA[y:J],  yizij,  jcZ,  iiyij  varying  z,y 

In  other  words,  assuming  that  the  goal  y=i  has  not  yet  been  achieved,  we  wish  to 
decrease  y  while  protecting  the  invariants  A[z]SA[yj]  and  yizij  along  with  the  added 
Invariants  ycZ  and  iiyij  for  termination. 

Since  we  are  assuming  that  /eZ  and  iiy'  hold,  end  we  know  that  for  the  loop  to  be 
continued  y'*l ,  it  follows  that  i<y’-\  .  So,  In  order  to  achieve  i<y  ,  we  need  to  achieve 
y'~l£y  .  This,  together  with  the  additional  requirement  that  y(y'  and  yeZ  ,  forces  y*y'- 1  • 
After  assigning 

y  >  y-i  . 

the  remaining  goal  Is 

assert  A[z]£A[y+\:j],  y*\Szij 
achieve  A[z]iA[y.j],  y<z<j  varying  z  . 

Since  the  value  of  y  has  changed,  we  have  broken  the  protected  clause  Into  an  assertion 
that  the  conjuncts  held  for  the  previous  value  of  y  and  z  and  a  gral  to  reachieve  them 
lor  y- 1  .  The  assignment  to  y  is  protected  by  only  varying  z  in  this  goal. 

Part  of  the  above  goal  has  already  been  achieved  and  part  remains  to  be  achieved. 
Using  the  following  basic  fact  about  universal  quantifiactlon: 

fact  p[u\v]  when  ^[u:v],  f[v«l:v],  uiuSv  , 

we  can  break  the  conjunct  A[z]SA\y:)]  Into  two  parts: 

purpose  AlzJ&AtyJl  ySzSj 

achieve  A[z]ZA[y:w],  A[z]sA[w+l:j],  y&wij,  yizij  varying  z,w 
assert  A[z]SA\j:j],  yizij 
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Since  we  heve  already  asserted  ^[z']Si4[y+I:J]  and  y<y+liz'£J ,  we  may  achieve 
A[z]ZA[w+\:j]  ,  yintij  ,  and  ySxij  by  leaving  z  unchanged  and  letting  wy  .  We  are  left 
with  only 

achieve  A[z]£A[y]  . 


This  latest  goal  has  an  empty  variable  list;  It  can  cnly  be  achieved  by  proving  that  It 
is  true  or  testing  that  It  is  true.  Since  it  cannot  be  proved  true,  we  use  the  conditional  rult 
to  generate 

if  A[z]*A[y]  than 

else  assert  A[z]iA[y*\:j],  y+lizij,  /([}]</<[z] 

achieve  A[z}SA\j:w},  A[z]SA[w*  1  :j],  y$w<], 

y<z<j  varying  z,ui  . 

fi  . 

The  then-clause  is  empty,  since  yf[zJS/f[>]  holds  at  that  point  by  virtue  of  the  test;  when 
the  conditional  test  is  false,  we  may  use  that  fact,  along  with  the  fact  that  the  invariants 
held  for  the  prior  value  of  y  to  achieve  the  previous  goal.  We  know,  then,  that 
A[y]<A[z']^A[y+ 1  :J]  ,  so  to  achieve  A[z]£A[w+ 1  :j]  we  let  z=y*w  .  Substituting  for  z  and 
w  ,  we  have 


achieve  z-yw,  ySyij  varying  z.w  . 

Since  jf[z]3^[y+l;j]  and  y*lSj  have  already  been  asserted,  this  reduces  to  just 
achieve  z-y  varying  z  . 

Achieving  this  via  an  assignment  statement,  we  obtain  the  conditional 
if  than  else  z  y  fi  , 

or  simply 

if  ^[j]<^[z3  than  z  :«  y  fi  . 


We  have  derived  this  program  for  minimum; 
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1  pr 

begin  commsnt  array  minimum-position  progam 

1 

assart  i.jc II,  isj 

(*,y)  >  (j.j) 

loop  assart  Alz]£A[y:j],  yeZ,  HyizSjf 

until  y*i 

y  >  ?-« 

if  A[y]<A[t]  than  z  :•  y  ti 

repast 

assart  A[z]iA[i:j],  iizSj 

1 _ 

and  . 

J 

In  the  next  section,  we  shall  see  how  to  extend  this  program  to  achieve  the  added  relation 
x*i4[z]  . 


Example  3:  Partition. 

In  this  last  synthesis  example,  we  consider  the  Partition  problem:  given  an  array 
segment  A[i:j] ,  rearrange  its  elements  so  that  there  exists  some  position  g  which 
partitions  the  segment  into  two  ordered  parts.  In  other  words,  each  element  of  the  left 
part  Is  to  be  less  than  or  equal  to  each  element  of  the  right  part  A[g+l:j]  .  The 

goal  specification  may  be  expressed  as 

f - 1 

|  Py  begin  comment  partition  program  | 

|  assert  i.jeN,  i<J  | 

j  achieve  A[i:gJsA[g+iy],  iig,  g+\Zj,  bag(A[i$}'hbog(A’[t:jl)  varying  A.g  | 

|  ,  | 

U  —  -  ■ 

where  A ’  represents  the  prior  value  of  the  array  A  .  The  function  bag(A[u:v])  yields  the 
multiset  M[u],  /f[u+l],  .  .  .  ,  A[v]} ;  thus,  the  fourth  conjunct  of  the  goal  implies  that  the 
new  array  segment  must  be  a  permutation  of  the  original  segment.  We  illustrate  two 
possible  solutions. 


As  •  first  try,  we  strengthen  the  goal  specification  using  the 
fact  p[u'.u]  when  p(u) 

to  eliminate  the  quantifier  [f:g]  .  What  we  wish,  then,  is  to 

achieve  A[i]iA[g+l:j],  g*t,  bag(A[i.j])*bag(A'[i:j])  varying  A,g 

(the  subgoals  iig  and  g+lZj  were  deleted  since  they  follow  from  the  new  goal  g-i  and 
the  assertion  Kj  .)  The  subgoal  g*l  can  be  achieved  by  the  assignment 

g  >  i  . 

leaving  only 

achieve  A[l]<,A[l*\.j],  bag(A[i\j])~l*ig(A’[i:j])  varying  A  . 

We  have  already  seen  how  to  synthesize  a  program  to  find  the  position  of  a  minimal 
element  of  an  array;  so  we  know  how  to 

achieve  yf[z]<if[f+l:f],  i+liz£j  varying  x  . 

This,  along  with  the  transitivity  of  inequality, 

fact  uio  when  uiw,  uSv  , 

suggest  strengthening  the  above  goal  to 

achieve  w*A[i+l\j],  varying.  A.w  , 

where  the  new  program  variable  w  can  be  set  to  any  convenient  value.  Comparing  what 
we  have  with  what  we  want  suggests  letting  and  splitting  the  goal  into  the 

disjoint  goals 

achieve  /f[z  ]$,<[*♦  I  :j],  i+lSzSj,  varying  z 

achieve  /f[f]2/4[z]  protecting  A[z]SA[l*\:j),  i*]<z<j, 

tog(A[i.j])*bogW[i:j'})  varying  A  . 

The  permutation  requirement  In  the  first  goal  Is  satisfied,  since  that  goal  does  not  vary  A  , 
l.e.  A’*A  ;  the  rest  Is  achieved  by  the  old  minimum  program.  To  achieve  the  second  goal 
>f[i]£^[z]  ,  one  might  try  to  assign  A[z]:*A[i]  ,  but  that  would  not  protect  the  permutation 
requirement.  We  can  however  test  if  already  holds: 

if  A[l]£A[z)  then 

else  assert 

achieve  A[i]SA[t']  protecting  .  .  .  varying  A 

fi  . 

T 


>  « 
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Knowing,  for  the  else-branch,  that  suggests  achieving  A[i]iA[z]  by  letting 

A'[z]~A[i]  and  A’[i]*A[z]  .  Since  iizi)  ,  this  also  protects  the  permutation  requirement 
tog(A{i:j]hbag(A'[i:j]) .  We  have 

if  then 

else  {A{l],A[tyi  :•  (A[z),A[i)) 
fi  . 

Accordingly,  our  first  solution  is 

r - 1 

|  Pt:  begin  comment  first  partition  program  | 

|  assert  t.jekl,  i<j  | 

|  6  :■  <  | 

I  l*.y)  V.J)  | 

[>  loop  assert  A[z]iA[y:j],  yizi)  j 

I  until  y=i+l  j 

I  y  :■  jH  | 

j  if  if[ji3<i4[r]  then  *  :*  y  fi  J 

j  repeat  j 

j  if  A[z)<A[i]  then  (/f[l]^W)  i])  fi  j 

j  assert  A[i:g}iA[g*l:)),  tig,  g*\i),  1 

|  end  .  j 

I _ I 


This  program  leaves  something  to  be  desired.  Despite  the  fact  that  it  Satisfies  the 
stated  specifications  and  that  It  Is  not  inefficient,  the  fact  that  for  the  usual  applications  of 
Partition  it  is  desirable  that  g  be  closer  to  the  mean  of  i  and  j  went  unspecified.  The 
above  program  always  results  in  g  being  equal  to  i . 


2.  Second  Solution 

We  do  not  want,  then,  to  force  g*t .  Instead,  we  leave  g  variable  and  reconsider 
our  original  goal  (temporarily  leaving  out  the  permutation  requirement) 

achieve  A[i:g]iA[g*l:j],  tig,  g+lij  varying  A,g  . 

This  time,  we  first  strengthen  the  goal  by  Introducing  a  new  variable  h  to  replace  the 
expression  g*  I  : 

achieve  A[i:g]iA[h\)],  f+M,  iSg,  hi)  varying  A,g,h  . 
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Then  we  try  to  eliminate  the  double  quantifier  in  by  introducing  a  new 

variable  to  ,  using  the 

fact  u£v  when  u£w,  a£v  . 

This  yields 

achieve  A[i:g]£w,  tu£A[h:j],  g* l*h,  i£g,  h£j  varying  A,g,h,to  . 

There  are  now  four  variables  that  the  program  may  set:  A  ,  g  ,  h  ,  and  to  . 

Now  we  can  split  this  conjunctive  goal  into  two: 

achieve  A[i:g]£w,  w£A[ft:j],  i£g,  h£j  varying  A,g,h,w 
achieve  g+l«A  protecting  A[i:g]£w,  to£A[h:j],  i£g,  h<] 

varying  A,g,h,w  ; 

the  second  will  become  a  loop  with  exit  test  g+l*h  and  the  first  will  initialize  the 
invariants.  By  reducing  quantifiers  to  single  elements,  the  first  goal  may  be  strengthened 
to 

achieve  A[i]<w,  w£A[j],  g*i,  h=j  varying  A,g,h,to  , 

and  the  first  conjunct  may  be  further  strengthened  to  A[i]=w  : 

achieve  A[iym,  w£A\j],  g=i,  h=j  varying  A,g,h,w  . 

At  this  point,  we  would  like  to  assign  to  w  ,  g  ,  and  h  .  Before  we  can  do  that  we  must 
substitute  for  the  other  occurrence  of  w  : 

achieve  /f[i]=w,  gmi,  h*J  varying  A,g,h,w  . 

Splitting  this  into  two  disjoint  goals  and  assigning  we  get  (putting  the  permutation 
requirement  back  in): 

achieve  A[i]£A[j],  bag(A[i.]])*bag(.A'[l'.j ])  varying  A 
(g.h.w)  (i,),  A[iy  . 

As  in  the  first  solution,  the  remaining  subgoal  yields  the  conditional 
if  A[ipA\J]  then  (/<[<],  A\J])  M0].*[O)  «  • 

The  current  status  of  the  program  Is: 
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assert  i.jeN,  i<] 

if  A[ipA\j]  then  ^C/])  >  U\j],  A[i])  fi 
(g./i.w)  :■=  <t. ].A[i]) 
assert  «/=/f[i],  A[i]ZA\J],  g*i,  h~j 
loop  assert  Anglin),  w$A[h:j],  iig,  h<j 
until  g+l=h 

approach  g+\*h  protecting  y4[i:f]<u/,  u>sA[h:J],  iig,  h<j 

varying  A,g,fi,w 

repeat  . 


We  may  now  determine  bounds  for  g  and  A  and  apply  the  termination  rule.  Initially 
g=i<jBh„ ,  while  upon  termination  .  This  suggests  keeping  g.heZ  and  letting 

g  increase  from  i  to  its  final  value  gm  ,  while  A  decreases  from  j  to  A*  .  The 
resulting  bounds,  iigig^  and  h*<,h<j ,  combined  with  f^A^-KA^  implies  the  invariant 
g< A  .  So  to  ensure  termination,  we  require  that  g  and  A  remain  integers,  and  that 
progress  Is  made  by  Increasing  g  and/or  decreasing  A  ,  until  they  meet  somewhere  in  the 
middle.  Accordingly,  the  loop-body  subgoal  becomes 

achieve  g'<g,  h'ih,  g'<gVh'>h 

protecting  w<A[h:)],  g,heZ,  l<g<h<j  varying  A,g,  ft,w 

Splitting  the  two  quantifiers  into  the  range  that  has  already  been  achieved  and  the 
range  that  remains  to  be  achieved,  we  get 

achieve  g'ig,  h'ih,  g'<gVh'>h,  wiA[h:h'- 1] 

protecting  A[i:g]£w,  g,h€ Z,  i<g<h£j  varying  A,g,h,w  . 

We  shall  protect  A[i:g]iw  and  o>SA[h:j]  by  not  varying  w  or  any  of  the  elements  In  the 
array  segments  A[l:g]  and  .  Now  If  we  reduce  the  quantifier  [g'+l:g]  to  a  single 

element  (letting  g'+t*g  )  and  make  the  quantifier  [A:A'-1J  vacuosly  true  (insisting  that 
A>A'-l  ),  then  we  get 

achieve  g'Sg,  h'ih,  g'<gVh’>k,  A[g'+  l]Sw,  g'+l*g.  A>A'-1, 

protecting  viA[ft:j],  g,  AcZ,  lig<hSj  varying  A,g,h  , 

which  simplifies  to 

achieve  £'♦!■{,  A'- A,  /f[f'*l]Sw 

protecting  wSW[A:j]  varying  A,  g,  A  . 

The  conditional  rule  suggests  achieving  the  conjunct  /<[£'+ l]$v  bytesting: 
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if  A[g+l]£w 


fi  . 


then  g  :•  g*  I 
else  assert 

achieve  g'ig,  k'Zh,  g’<gVh'>h, 

n/iii[A:A'-l]  protecting  .  .  .  varying  g,h  . 


Without  going  Into  more  detail,  the  remaining  subgoal  generates  two  more  cases:  if 
,  then  h  Is  decremented  by  I  ;  otherwise,  ,4[A'-I]<b/<^[^'+1]  and  vf[A'-l]  is 
exchanged  with  Alg**  1]  and  both  g  Is  increased  and  h  decreased.  The  completed 
program  Is: 

j  - 1 

I  begin  comment  partition  program  | 

|  assert  i,je\ti,  Kj  j 

|  if  A[i]>A\j}  then  (A[i],A\J])  :«  (A\jl  ^[t])  fi  | 

|  (g,h,  tv)  :*  (i,J,A[i ])  j 

|  loop  assert  A[i:g]<miA[h:j],  g.heZ,  iZg<hij  | 

j  until  | 

if  A[g+l]Sw  then  g  >  g* I  1 

|  else  if  wS^A-l]  | 

j  then  A  :*  A-l  j 

j  else  ig.h)  :*  (g+l.A-l)  | 

I  MW.  >«M>  :=  lA[h].A[g])  j 

I  fi  j 

I  fi  \ 

j  repeat  j 

j  assert  A[i:g]iA[g*\:j],  isg,  g+\<]  j 

j  end  .  j 

»—  —  .  i 
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6.  EXTENSION 

In  this  section,  we  Illustrate  techniques  for  extending  a  given  program  to  achieve  an 
additional  relation.  There  are  two  basic  methods.  One  Is  to  append  code  at  the  end  of  the 
program  with  the  purpose  of  achieving  the  additional  goal,  while  making  sure  that  the 
relations  already  achieved  by  the  program  remain  intact.  The  second  method  is  to  achieve 
the  added  relation  at  the  outset  and  modify  the  program  to  ensure  that  It  maintains  that 
relation  true  until  the  end  of  the  execution. 

This  second  method  Is  also  used  for  local  optimization:  If  a  program  contains  an 
expression  that  Is  relatively  difficult  to  compute,  but  must  be  recomputed  for  each  loop 
Iteration,  then  it  may  be  possible  to  Introduce  a  program  variable  that  will  Invariantly 
contain  the  value  of  the  complex  expression,  and  for  which  there  is  a  relatively  simple  way 
of  deriving  the  new  value  of  the  variable  from  the  old  value.  This  new  variable  must  be 
updated  whenever  the  value  of  a  variable  in  the  expression  is  changed,  and  may  be 
substituted  for  that  expression  wherever  it  occurs  In  the  program  text. 


Example  Is  Array  Minimum. 


Consider  our  program 

I - 1 

|  Pf:  begin  comment  array  minimum-position  program  | 

|  assart  i.jcN,  i<j  | 

|  (z,y)  >  (j.j )  | 

j  loop  assert  yizsj  j 

|  until  y=i  j 

I  y  H  I 

(  if  A[y]<A[z]  then  z  :«  y  fi  | 

j  repeat  j 

j  assart  A[z]SA[i:J],  ISzSj  j 

|  end  ,  | 

l _ l 

and  assume  that  we  wish  Instead  to 


achieve  tezSj,  x*/4[z]  varying  z,x  . 

The  above  program  only  achieves  the  first  two  conjuncts  of  the  new  goal;  we  must  extend 
the  program  to  achieve  the  additional  conjunct  xM[z ]  as  well. 
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One  simple  way  to  accomplish  this  would  be  to  split  the  new  goal  into  two  disjoint 
goals: 

achieve  A[z]ZA[i:j],  iitij  varying  z 
achieve  x=A[z]  varying  x  . 

For  the  first,  we  already  have  a  program;  for  the  second,  we  may  simply  append  the 
assignment 

*  A[x)  . 

A  second  possibility  would  be  to  begin  by  achieving  the  relation  x->4[z]  ,  and  then 
protect  that  relation  while  achieving  i4[z]2i4[f:j]  via  Pt .  In  other  words  the  relation 
x*A[z]  should  be  a  global  invariant  of  Pt ,  holding  throughout  execution  of  the  program. 
In  order  to  accomplish  this  goal,  viz. 

achieve  x*A[z ]  in  Pf  varying  x  , 

we  must  set  x  to  the  appropriate  value  whenever  the  variable  z  changes  value.  The 
assignments  to  z  are 

z  :■  j  *  =-  7  ■ 

When  z  is  initialized  to  j  ,  we  initialize  x*A[z]  to  A[j]  ;  when  z  is  reset  to  y  ,  we  reset 
x  to  .  This  yields  the  program 

(z.j.x)  :«  (j,J,A[j ]) 
loop  assert  A[z]SA[y:j],  ySzSj 
until  j*i 

y  :■  y  I 

if  then  <z,x)  :■  (j,i4[y])  fi 

repeat  . 

As  It  stands  now,  the  first  alternative  requires  less  computation.  But  since  we  have 
established  the  global  invariant  x»yf[z]  ,  the  conditional  test  if[^]<yf[z]  may  be  simplified 
to  >J(jO<x  .  The  final  version  of  this  program  is 
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assart  xM[z]  in 

Pt':  basin  commant  txttndtd  array-minimum  program 
assart  i.jeH,  i<j 
(z.y.x)  :»  (J.J,  A[jV 
loop  assert  A[z]sA[y:J],  yizSj 
until  y *i 
y  :*  y-l 

if  A[y]<x  than  (z,x)  :»  (y,  A[y])  tl 

rapaat 

assart  A[z]SA[i:j],  iSzS] 

and  . 


In  a  similar  manner,  we  could  begin  with  the  program 

1 - 1 

|  P"\  basin  commant  txttndtd  array-minimum  program  | 

|  assart  iJeN,  IS]  | 

|  (>,*)  :»  | 

j  loop  assart  xSAly-.j]  | 

j  until  y=i  | 

I  y  >  y-i  .  I 

]  if  >4(j)]<x  than  x  >  fi  | 

|  repeat  | 

j  assart  x$<4[i:j]  j 

I  «nd  j 

l _ i 

that  only  achieves  x2i4[i:j]  ,  and  extend  It  to  achieve  x*A[z]  as  well.  There  is  no  easy 
way  to  set  z  at  the  end  of  P"  so  that  x*if[z] .  But  we  can 

achieve  x*A[z]  in  P"  varying  x 

by  examining  the  assignments  to  x  , 
x  :•  A[J ]  x  :■  . 

The  corresponding  assignments  to  z  would  be 
z  :•  J  z  y  , 
yielding  the  same  program  as  P,' . 


Example  2t  Inttgtr  S quart -root. 
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In  our  program, 

I - 1 

|  P':  begin  comment  inttgtr  squart-root  program  j 

|  assart  acN  j 

j  x  0  j 

|  loop  assart  z^ia.  zeN  j 

|  until  a<(z+l)2  | 

j  t  :*  Z4|  j 

|  rapaat  | 

|  assert  z*[Va\  ! 

|  end  ,  j 

I _ I 

the  exit  test  a<(z+|)2  Is  relatively  difficult  to  compute  as  it  involves  squaring.  It  may  be 
replaced  by  a<s  ,  if  we  can  extend  Pt  to  achieve  the  global  invariant  j*(z+|)2  : 

achieve  i*(z4l)2  in  P  t  varying  s  . 

The  variable  z  is  set  by  two  assignments  in  the  program 
z  :*  0  z  :■  Z4 1  ; 

we  must  assign  appropriate  values  to  :  to  maintain  the  desired  relation  j=(z4l)2  . 

One  way  to  accomplish  this  is  to  use  a  collection  of  rules  that  relate  assignment 
statements  to  the  values  of  the  program  variables.  One  of  them  states  that  in  order  for  a 
global  assertion  of  the  form 

assert  (>-60)*2<a,2*(x-«„)-[6)*(x-o0-«5)42-as‘(6t46|-a0)]  in  P 
holds  If  the  assignments  to  x  and  y  in  P  are  of  one  of  the  two  forms 
(x,y)  («0,60) 

or 

(x.y)  :■  {x*ai,y*bl-x*^)  , 

where  at ,  b0 ,  a, ,  6, ,  and  are  of  constant  value  In  P  . 

Let  us  try  to  apply  this  rule  to  the  problem  at  hand.  We  match  x  and  y  in  the  rule 
with  z  and  s  in  the  program,  respectively.  The  assignments  to  z  are 


z  :«  0 


z  :*  z+ 1  , 
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so  we  let  at  »*  0  and  s,  ■*  I  .  Thus,  assignments  of  the  form 
(z.i)  :«  (0,6„)  (z,i)  :«  (z *l,s+bt*z*bt) 

achieve  the  relation 

(J  l2«(*-0).[S,-(z-0- 1  )+2*  1  •(S,+6,*0)3 
i.e. 

O-60)*2«z-[V(z-l)*2-6s]  • 

So  we  are  looking  for  instantiations  of  b0,  bt  ,  and  6, ,  such  that 

(i-60)*2=z‘[&,*(z-l)+2*i>}]  =>  i*(z+l)2  . 

Isolating  s  to  the  left  of  the  equality  and  matching,  leaves 
*•[&,*(*- 1)/2*6.]+&0  (*♦>)*  • 

Transforming  (z*l)2  into  z*(z+2)+ 1  ,  suggests  fe„=*l  and 
/>,*(z-l)/2+^  =»  z+2  , 

which,  in  turn,  suggests  bt  =>  2  and  6,  3  .  Instantiating  .  bf ,  and  b}  back  into  the 

assignments,  we  get 

(z,j)  :■=  (0,1)  (z.j)  :=  (z+l, j*2*z+3) 

A  further  improvement  would  be  to 
achieve  f=2*z+3  in  Pf'  . 

By  another  rule  (<>  In  the  appendix),  to  get 
assert  <V(?-ty=&,*(x-a0)  in  P  , 
the  proper  assignments  are 

(x,y)  :«  (a0,b0)  (x,y)  :=  (x*a,>u,y*bt>u)  . 

This  suggests  the  Instantiation 

(x  ■*  z,y  f,a„  0,«,  =»  l,u  -»  I)  , 

leaving 


(t-b^sb^z  =*  f»2*z+3  . 
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Taking  be  ■*  3  and  bf  «♦  2  ,  we  gat  the  assignment* 

U.s.t)  :«  (0,1,3)  (z,;,f)  :■  (z*l.i*f,l*2)  , 

and  the  program 


assart  j=(z+l)2,  f*2‘z*3  in 

begin  comment  famous  integer  square -root  program 
assert  acN 

(z.r.f)  :=  (0,1,3) 

loop  assert  z^Za,  zeM 
until  a<s 

( z,s,t )  :*  (z*l,s*t,t+2) 

repeat 

assert  z-[VaJ 
end  . 


Example  3i  Binary  Integer  Square-root. 

At  the  conclusion  of  the  overview  chapter,  we  had  obtained  the  following  binary 
integer  square-root  program: 

f - 1 

|  assert  aeN,  zeM,  ?e2N  in  | 

j  P,:  begin  comment  binary  Integer  square-root  program  | 

|  assert  aeM  | 

j  (z.j)  (0,1)  j 

|  loop  until  a<;2  j 

I  y  >  *y  I 

j  repeat  | 

|  loop  assert  zzVa,  Va<z*y  \ 

j  until  ysi  j 

I  y  >  yn  I 

|  if  (z*yj*Za  than  *  :•  z*y  fi  | 

j  repeat  j 

|  assert  zZVa,  Va<t*  1,  zeM  [ 

end  . 
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In  this  program,  the  exit  test  a<fi  and  conditional  test  (z*yfiia  are  the  most  expensive 

expressions  to  compute.  The  latter  is  equivalent  to  z%+2*yz*y^£a  ,  and  assuming  that  we 
can 


achieve  u-z 2,  v-2 yz,  w=y^  in  P,  varying  u,v,u  , 
we  may  replace  the  tests  with  a<w  and  u+v+w Sa  ,  respectively. 

Whenever  z  or  y  Is  updated,  the  new  variables  u  ,  v  ,  and  w  must  be  updated 
correspondingly  so  that  their  relations  with  z  and  y  remain  invariant.  In  a  manner  similar 
to  the  previous  example,  we  obtain 

r - 1 

|  assert  acN,  zcN,  ye2^,  u-z v*2yz,  w*y%  in  | 

|  Py  begin  comment  extended  binary  integer  square-root  program  | 

|  assert  aeN  | 

|  (z.y, u,v,w)  :=  (0, 1,0,0, 1)  | 

|  loop  until  a<w  | 

j  (y,  to)  :=  (2y,  4*a0  | 

|  repeat  | 

|  loop  assert  zSVa,  Va<z*y  I 

j  until  y<  1  j 

|  (y,v,w)  :=  (y/2,  v/2,  w/i)  \ 

|  if  u+v*w£a  then  (z,u,v)  :*  b+y,u*v*w,v*2'ii>)  fi  j 

j  repeat  j 

|  assert  zSVa,  Va<z+1,  zcN  | 

j  end  .  j 

l _ i 

The  variable  z  affects  only  the  value  of  z  itself,  so  it  is  a  candidate  for  elimination 
from  the  program.  The  only  problem  Is  that  It  Is  z  that  contains  the  desired  final  result. 
Fortunately,  since  we  have  the  global  Invariant  *-Z7»z  ,  we  can  just  append  the  goal 

achieve  v*=2*j*z  varying  z 

to  the  end  of  the  program.  We  shall  return  to  this  unachieved  goal  later. 

Once  we  have  eliminated  the  assignment  z:*z*y  ,  the  variable  y  only  affects  the  the 

exit  test  yi\  .  But  we  can  replace  the  variable  y  with  Vi  ,  since  wy?  and  y  is  known 
to  be  positive.  This  gives  us  the  exit  clause 

until  Vis  I  , 


for  which  the  primitive 
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until  0/31 
may  be  substituted. 

Squeezing  the  last  drop  of  ink  out  of  this  example,  we  obtain  yet  another  slight 
Improvement:  To  transform  the  test  u+o+wia  ■»  u*v*wS0  ,  we  can  apply  the  transformation 
u  «♦  u+a  ,  yielding  the  initialization 

(u.v.tv)  :•  (-a,  0,1) 

and  conditional 

if  u* v+w£0  than  (it,i/)  :■  (u+v*w,v+2>w)  fl  . 

To  avoid  recomputing  the  expression  u*o*u  for  both  the  conditional  test  u+v+w<a  and 
the  assignment  u:“u*v*tu  ,  a  temporary  variable  could  be  generated,  say  t ,  such  that 
t*u+v+w  .  It  would  then  be  used  in  the  test  ti 0  and  assignment  (u,  v*2 *w) . 

Incorporating  the  above  improvements,  we  obtain 

I - 1 

|  assert  ocN,  zcN,  j€2w,  u*a*z%,  »«2*y**,  in 

|  P':  begin  comment  optimized  integer  square-root  program 
{  assert  aeN  ' 

I  (u.v.w)  :«  (-a.O.l) 

j  loop  until  a<w 

|  w  :=  i>w 

|  repeat 

|  loop  assert  ziVa,  Vaiz*y 

j  until  »3l 

|  («,s/)  :■  (z>/2,  ru/i) 

|  t  :*  u*v*w 

j  if  ISO  then  (u,v)  :■  (t,p* 2’w)  fl 

j  repeat 

I  achieve  v*2 yz  varying  z 
|  assert  z3Va,  Va<*4l,  zcN 

{  end  . 

i _ i 


•  -t^^wi-  :i'sflSfc*'it-.  - 
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Finally,  another  drop  of  computation  Is  saved  by 
achieve  s*v+a  varying  s  . 

Since  v*0  upon  entering  the  second  loop,  we  set  s:*w  at  that  point.  When  v  is  halved 
and  w  Is  quartered,  the  new  value  of  s  should  become  v/2*w/i=v/2*w/2-w/4*s/2-u>/i  . 
So  as  not  to  compute  a/i  twice,  we  may  first  assign  a:*u/i  and  then  s:*s/2-w  .  When 
v  is  incremented  by  2‘w  ,  so  must  t  be.  We  can  now  eliminate  v  from  the  program.  For 
the  second  loop,  we  have 

s  :*  w 

loop  assert  ziVa,  Va<z*y 
until  w£i 
a  :*  wli 
s  :«  si 2-o/ 

I  :«  u+s 

if  0  then  (u,j)  :»  (f,  j+2*w)  fi 

repeat  . 


We  still  have  the  goal 

achieve  v=2*yz  varying  z  . 

Though  y  and  v  are  now  ghost  variables,  we  know  that  s-v*w  ,  w=y r  ,  and  .  From 
these  global  Invariants  and  the  exit  test  u<  I  ,  we  conclude  that  w=y=l  upon  ter/nination 
of  the  second  loop.  Thus,  to  achieve  the  above  goal,  we  need  only 

achieve  ;-l=2*i*z  varying  z  ; 

we  therefore  assign 

*  :=  0-0/2  . 

The  transformation  a  ■*  a/2  gives  us  our  final  version  of  this  program  (cf.  Oijkstra 
[1076]): 


assart  oeW,  zeN,  j>e2^,  u*a*x^,  v«2*?*z,  w*2*^,  s=v*w/ 2  in 
P"\  begin  comment  improved  integer  square-root  program 
assert  aeN 
(u,ui)  :*=  (-a,  2) 
loop  until  2*o<w 
w  :* 
repeat 
*  :*  ta/2 

loop  assert  zS-Za,  Va<z*y 
until  wi2 

w  :=  w/4 
s  :=  (j-w)/2 
r  :=  tt+j 

if  fSO  then  ( u,s )  :■  (t,s*u)  fi 
repeat 

z  :=  (i-D/2 

assert  zSVa,  Va<z+1,  zcN 

end  . 


We  have  successfully  replaced  the  original  exit  test  a<y r  and  conditional  test 
(z*y)2$a  ,  both  of  which  involve  squaring,  a  relatively  expensive  operation,  with  the  simple 
tests  2««<a/  and  ttO  .  This,  at  the  cost  of  updating  the  variables  by  addition/subtraction 
and  muitiplication/dlvision  by  powers  of  two,  relatively  cheap  operations  on  binary 
computers. 

The  real  square-root  program 
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may  be  optimized  in  a  similar  manner  to  obtain  Wensley's  [1959]  square-root  algorithm: 

f - 1 

J  assert  a*i4u>y=z^  in  i 

|  begin  comment  optimized  real  square-root  program 
j  assert  0<a<l,  0<e  j 

j  ( z.y.u )  :=  (0,  1/2,  -a/2)  | 

|  loop  assert  ziVa,  Va<z+ 2*y  I 

|  until  y<2-e  | 

|  (y,u)  :=  (>/2. 2*u)  j 

|  t  :=  u+z+y  I 

j  if  t< 0  then  (z,  u)  :=  (z*24y,t)  fi  j 

|  repeat  ] 

|  assert  z<Va,  Vaiz+e  j 

S  end  .  | 

l _ l 


in  this  chapter,  we  have  seen  how  to  systematically  develop  a  program  from  its 
specifications;  in  the  next  chapter  we  shall  see  how  similar  ideas  may  be  employed  to 
generate  the  invariants  from  the  code. 
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CHAPTER  VI 
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1.  INTRODUCTION 

As  we  have  seen,  invariant  assertions  are  often  needed  for  modifications  to  carry 
through.  But  what  if  the  programmer  failed  to  supply  enough  of  them?  In  particular,  if  the 
program  is  incorrect  with  respect  to  its  specifications,  then,  perforce,  some  of  the  given 
assertions  (at  very  least,  the  output  specification)  do  not  reflect  what  the  program  is 
actually  doing.  And  without  knowing  what  the  program  is  doing,  we  cannot  proceed  to 
debug  it. 

Program  annotation  Is  the  process  of  discovering  invariant  assertions  from  the  program 
text  itself.  Our  task  is  to  generate  the  invariants  describing  the  workings  of  the  program 
as  is,  independent  of  Its  correctness  or  incorrectness.  The  process  is  iterative,  since 
finding  some  invariants  suggests  others.  Assertions  supplied  oy  the  programmer  cannot  be 
assumed  true,  though  they  may  be  used  to  guide  the  search  for  correct  invariants. 

If  the  invariants  associated  with  the  point  of  termination  of  a  program  imply  that  the 
given  output  specification  Is  true  for  any  Input  satisfying  the  input  specification,  then  the 
program  has  been  proved  correct.  On  the  other  hand,  if  there  exist  legal  input  values  such 
that  whenever  the  output  invariants  hold  for  those  Input  values,  the  specifications  do  not 
all  hold,  then  the  program  is  incorrect,  in  this  manner,  invariants  are  used  for  proving 
correctness/incorrectness  of  programs. 

Existing  implementations  of  the  invariant-assertion  method  of  program  verification  are 
not  fully  mechanical;  the  user  must  supply  most,  If  not  all,  of  the  invariants  himself.  If  the 
original  program  'is  not  supplied  with  sufficient  Invariants  to  prove  correctness  or 
incorrectness,  they  must  be  supplemented.  These  invariants  then  enable  one  to  verify  if 
what  the  program  does  is  what  it  was  intended  to  do.  Invariants  are  also  useful  in 
analyzing  other  properties  of  programs,  e.g.  time  complexity. 

In  the-  following  sections,  we  present  a  unified  approach  to  program  annotation,  using 
annotation  rules  —  in  the  style  of  Hoare  [1969]  —  to  derive  invariants.  Section  2  is  an 
overview.  It  Is  followed  by  two  detailed  examples:  the  first  illustrates  the  basic 
techniques  on  a  single-loop  program;  the  second  applies  the  techniques  to  a  program  with 
nested  loops  and  arrays. 

Three  earlier  annotation  systems  are: 

•  the  system  described  In  Elspas  [1974],  based  mainly  upon  the  solution  of  difference 
equations; 

•  VISTA  (German  [1974],  German  and  Wegbreit  [1976]),  based  upon  the  top-down 
heuristics  of  Wegbreit  [1974];  and 

•  ADI  (Tamlr  [1978]),  an  interactive  system  based  upon  the  methods  of  Katz  and  Manna 
[1978]  and  Katz  [1978]. 
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Our  annotation  system,  as  described  here,  attempts  to  incorporate  and  expand  upon  those 
systems.  Recently,  Suzuki  and  lahihata  [1877]  and  German  [1978]  have  implemented 
systems  that  generate  invariants  useful  in  checking  for  various  runtime  errors. 


2.  OVERVIEW 

in  this  section,  we  first  define  some  terminology  and  then  present  samples  of  each 
type  of  annotation  rule. 


1 .  Notation  and  Terminology 

Given  a  program  with  its  specifications,  our  goal  is  to  document  the  program 
automatically  with  invariants.  If  the  program  is  correct  with  respect  to  the  specifications, 
we  would  like  the  invariants  to  provide  sufficient  information  to  demonstrate  its 
correctness;  If  the  program  is  Incorrect,  we  would  like  information  helpful  in  determining 
what  is  wrong  with  It. 

We  shall  be  dealing  with  three  types  of  assertions: 

•  Global  invariants  are  relations  that  hold  at  all  places  (i.e.  labels)  and  at  all  times  during 
the  execution  of  some  program  segment.  We  write 

assert  a  in  P 

to  Indicate  that  the  relation  a  is  a  global  invariant  in  a  program  segment  P  .  (Actually, 
a  Is  considered  a  global  invariant  even  If  It  only  begins  to  hold  once  the  variables  in  a 
have  been  assigned  an  Initial  value  within  P  .) 

•  Local  invariants  are  associated  with  specific  points  in  the  program,  and  hold  for  the 
current  values  of  the  variables  whenever  control  passes  through  the  corresponding  point. 
Thus, 

L :  assert  or 

means  that  the  relation  a  holds  each  time  control  Is  at  label  L  . 

•  Candidate  assertions,  also  associated  with  specific  points,  are  relations  hypothesized  to 
be  local  Invariants,  but  that  have  not  yet  been  verified.  We  write 

L:  suggest  a  . 

Consider  the  following  simple  program,  meant  to  compute  the  quotient  q  and 
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remainder  r  of  the  Integer  input  values  e  and  d  : 

f - 1 

|  Pt:  begin  comment  integer -division  program  I 

j  B0:  assert  ceN,  rfeN+l  | 

I  (q,r)  (0 ,c)  | 

j  loop  L0:  assert  ...  [ 

|  until  rid  | 

j  (q,r)  :=  (q*l,r-d)  | 

|  repeat 

|  £„:  suggest  q<c/d,  c/d<q* I,  qtl,  r*c-q'd  | 

|  end  ,  | 

i . . I 

where  IJ  is  the  set  of  nonnegative  Integers,  N+l  is  the  set  of  positive  Integers,  and  Z 
is  the  set  of  all  integers.  This  program  will  be  used  only  to  illustrate  various  aspects  of 
program  annotation;  complete  examples  of  annotation  are  given  In  the  next  section. 

The  invariant 

assert  ccM,  1 

attached  to  the  begin-label  Br  Is  the  Input  specification  of  the  program  defining  the 
class  of  "legal"  Inputs.  The  input  specification  is  assumed  to  hold,  regardless  of  whether 
the  program  is  correct  or  not. 

The  candidate 

suggest  q<c(d,  c/d<q*\,  qt Z,  r*c-q*d 

attached  to  the  end-label  £(  Is  the  output  specification  of  the  program.  It  states  that 
the  desired  outcome  of  the  program  is  that  q  be  the  largest  integer  not  larger  than  c/d 
and  r  be  the  remainder.  Since  one  cannot  assume  that  the  programmer  has  not  erred, 
Initially  all  programmer-supplied  assertions  —  including  the  program's  output  specification  — 
are  only  candidates  for  invariants. 

In  order  to  verify  that  a  candidate  is  indeed  a  local  invariant,  we  must  show  that 
whenever  control  reaches  the  corresponding  point,  the  candidate  holds.  Suppose  that  we 
are  given  a  candidate  for  a  loop  invariant 

L„:  suggest  r*c-q'd  . 

To  prove  that  it  is  an  invariant,  one  must  show:  1)  that  the  relation  holds  at  L„  when  the 
loop  is  first  entered,  and  2)  that  once  it  holds  at  £„ ,  it  remains  true  each  subsequent  time 
control  returns  to  L„ .  If  we  succeed,  then  we  would  write 


134 


;4 


L„:  assert  t*c-q*d  . 

Furthermore,  if  r-c-q>d  holds  whenever  control  Is  at  Lo ,  then  it  will  also  hold  whenever 
control  leaves  the  loop  and  reaches  £e .  In  other  words,  r*c-q>d  would  also  be  an 
invariant  at  £„  and  may  be  removed  from  the  list  of  candidates  at  £„ .  In  that  case,  we 
would  write 

E0:  assert  r-c-q-d  and  surest  qic/d,  c/d<q* I,  qe Z  . 

Global  invariants  often  express  the  range  of  variables.  For  example,  since  the 
variable  q  is  first  initialized  to  0  and  then  repeatedly  Incremented  by  1 ,  it  is  obvious  that 
the  value  of  q  is  always  a  nonnegative  Integer.  Thus  we  have  the  global  invariant 

assert  feN  in  Pt 

that  relates  to  the  program  as  a  whole  and  states  that  qeN  throughout  execution  of  the 
program  segment  P0 . 

In  this  chapter,  we  describe  various  annotation  techniques.  These  techniques  are 
expressed  as  rules:  the  antecedents  of  each  rule  are  usually  annotated  program  segments 
containing  invariants  or  candidate  Invariants  and  the  consequent  is  either  an  invariant  or  a 
candidate.  This  list  is  representative  of  the  kinds  of  rules  that  may  be  used  for 
annotation;  it  is  not,  however,  meant  to  be  a  complete  list.  Not  only  are  these  rules  useful 
for  automatic  or  interactive  annotation,  but  they  help  to  clarify  the  interrelation  between 
program  text  and -invariants  for  the  programmer. 

We  differentiate  between  three  types  of  rules:  assignment  rules,  control  rules,  and 
heuristic  rules. 

•  Assignment  rules  yield  global  Invariants  based  only  upon  the  assignment  statements  of 
the  program. 

•  Control  rules  yield  local  invariants  based  upon  the  control  structure  of  the  program. 

•  Heuristic  rules  have  candidates  as  their  consequents.  These  candidates,  though 
promising,  are  not  guaranteed  to  be  Invariants. 

The  assignment  and  control  rules  are  algorithmic  In  the  sense  that  they  derive  relations  in 
such  a  manner  as  to  guarantee  that  they  are  Invariants.  The  heuristics  are  rules  of  plausible 
inference,  reflecting  common  programming  practice. 
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2.  Assignment  Rules 

Many  of  tha  algorithmic  rules  depend  only  upon  the  assignment  statements  of  the 
program  and  not  upon  Its  control  structure.  In  other  words,  whether  the  assignments 
appear  within  an  iterative  or  recursive  loop  or  on  some  branch  of  a  conditional  statement  is 
irrelevant.  Since  the  location  and  order  in  which  assignments  are  executed  does  not 
affect  the  validity  of  the  rules,  these  rules  yield  global  invariants. 

The  various  assignment  rules  relate  to  particular  operators  occurring  in  the  assignment 
statements  of  the  program.  Some  of  the  rules  for  addition,  for  example,  are:  an  addition 
rule  that  gives  the  range  of  a  variable  that  is  updated  by  adding  (or  subtracting)  a 
constant;  a  sel -addition  rule  for  the  case  where  the  variable  is  added  to  another  variable 
whose  range  is  already  known;  and  an  addition -relation  rule  that  relates  two  variables  that 
are  always  incremented  by  similar  expressions.  Corresponding  rules  apply  to  other 
operators. 

For  example,  the  addition  rule  is 

x  :*  a0  x  :=  x+a,  x  :*  x*a}  ...  in  P 

assert  x€a0+at*N+at*N+  ...  in  P  , 

where  P  is  a  program  segment  and  the  expressions  a(  are  of  constant  value  within  P  . 
The  antecedent 

x  >  a0  x  :=  x+a,  x  >  x*at  ...  in  P 

indicates  that  the  only  assignments  to  the  variable  x  In  P  are  x>a^ ,  x:=x+a, ,  x:*x+e , , 
etc.  The  consequent 

assert  X€a(+a)*N+a|»N+  ...  in  P 

is  a  global  Invariant  indicating  that  x  belongs  to  the  set  a(+a(*N+<i!,*N+  .  .  .  throughout 
execution  of  P  —  but  only  from  the  point  when  x  first  receives  a  defined  value  in  P  via 
the  assignment  x:«e0 .  (After  any  execution  of  x:«a6 ,  clearly  x€ao+a(*N*a;4J*  .  .  .  with 
x«a0+c(‘0+e}*0+  .  .  .  ,  and  If  x*a0*a),m+a|*n*  ...  for  some  m  ,  n  , . . .  before 
executing  x:*x+a, ,  then  x«a0+a|«(m+l)+al*n4  .  .  .  after  executing  the  assignment.  Thus, 
m  represents  the  number  of  executions  of  x>x+a,  since  x:«=ap  was  executed  last,  n  is 
the  number  of  executions  of  x:«x+a, ,  etc.)  From  such  an  invariant,  more  specific 
properties  may  be  derived.  For  example  a  bound  on  x  may  be  derived  using  methods  of 
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interval  arithmetic  (see  for  example  Gibb  [1961]).  Note  that  no  restrictions  are  placed  on 
the  order  In  which  the  assignments  to  x  are  executed,  except  that  prior  to  the  first 
execution  of  x:«a#  the  invariant  may  not  hold. 

in  our  simple  program  Pt ,  the  assignments  to  the  variable  q  are 
q:*0  q>q*  I  . 

So  we  can  apply  the  addition  rule,  instantiating  a,  with  0  and  a,  with  i  ,  and  obtain  the 
global  invariant  f€0+i*N  ,  i.e. 

assert  fcN  in  P,  . 

The  assignments  to  r  in  P0  are 

r:»«  r:«r-d  . 

Applying  the  same  rule  to  them,  letting  a*c  and  a^-d  ,  yields  the  invariant 
assert  rec-d»N  in  P0  . 

Given  that  d  Is  positive,  we  may  conclude  that  ric  . 

The  set-addition  rule  is  a  more  general  form  of  the  above  addition  rule,  applicable  to 
nondeterministic  assignments  of  the  form  x:c/($) ,  where  an  arbitrary  element  in  the  set 
f(S)-[f(s):s€S)  Is  assigned  to  x  .  Note  that  an  assignment  x:*=/(j)  ,  where  it  is  only 
known  that  jcS  ,  may  be  viewed  as  the  nondeterministic  assignment  x:e/(5)  .  The 
set-addition  rule  Is 

x:eS,  x:ex*S,  x:ex*S,  ...  in  P 
assert  xeJg+ES^Si,*  ...  in  P  , 

where  £5  denotes  the  set  of  finite  sums  W  for  (not  necessarily  distinct) 

addends  s,  In  S  .  If  m»0  ,  the  sum  is  0  j  if  5  contains  the  single  element  s  ,  then 

£S*.f'N  .  (This  rule  applies  analogously  to  any  associative  and  commutative  operator  "©".) 
These  assignment  rules  for  global  invariants  are  related  to  the  weak  interpretation  method 
of  Sintzoff  [1972]  (see  also  Wegbreit  [1976],  Wegbrelt  and  Spitzen  [1976],  and  Harrison 
[1977])  that  has  been  implemented  by  Scherlis  [1974]  and  German  and  Wegbreit  [1976]. 
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In  program  Pt  the  assignments  to  r  were 
r:«c  r:*r-d  . 

Since  we  are  given  that  ceM  and  dckJ+l  ,  we  may  view  these  as  the  nondeterministic 
assignments 

rrcW  r:er-(W*J)  , 

and  by  applying  the  set-addition  rule  we  obtain  the  global  invariant  r€tJ-£(fcJ+l) .  This 
simplifies  to 

assert  reZ  in  Pc  , 
where  Z  Is  the  set  of  all  Integers. 

To  relate  different  variables  appearing  In  a  program,  we  have  an  addition -relation  rule: 

( x,y )  :*  («„,*„)  ( x.y )  :*  lx*a^u,y*b^u) 

(x,y)  :*  lx*at‘v,y*b^v)  ...  in  P 
assert  a, ‘(y-bt)*bt •(*-«,)  in  P  , 

where  u  ,  v  .....  are  arbitrary  (not  necessarily  constant)  expressions.  The  invariant 
begins  to  hold  only  when  the  multiple  assignment  (x,5>):=(a0,  bj  has  been  executed  for  the 

first  time.  (The  Invariant  «,*(>-30)=*, *(*-«„)  clearly  holds  when  x=ap  and  y=b0 .  Assuming  it 
holds  before  executing  (x,y):*(x+al>u,y+bl,u) ,  then  after  executing  the  assignment,  both 
sides  of  the  equality  are  increased  by  al,bl *u  ,  and  the  invariant  still  holds.)  The  multiple 
assignments  In  the  antecedent  of  such  rules,  e.g.  (x,y):={x*at‘U,y*b*u) ,  may  represent 
the  cumulative  effect  of  individual  assignments  lying  on  a  path  between  two  labels,  with 
the  understanding  that  whenever  *:«*♦«,•«  Is  executed,  so  Is  y:*y*bt‘U  for  the  same 
value  of  the  expression  u  .  In  that  case,  the  invariant  will  not,  in  general,  hold  between 
the  individual  assignments. 

In  our  example,  the  assignments  in  the  initialization  path  give  us 
(?.r):=(0,c)  . 

and  for  the  loop-body  path  we  have 
(q,r):*(q+l,r-d)  . 

By  a  simple  application  of  the  addition-relation  rule  with  «c*0  ,  b*c  ,  a(=u=v=l  ,  and  b*-d  , 
we  derive  the  invariant  1  •(r-c)*-rf»(^-0) ,  which  simplifies  to 


assert  r*c-q*d  in  P(  . 


Note  that  this  addition-relation  rule  (as  well  as  several  other  relation  rules)  may  be 
derived  from  the  following  general  relation-rule  schema: 

(*,j)  (a,,*,)  (x,y)  (*©(«©«,), y»(u9b,)) 

(x,y)  (x©(i>®al),j©(r®l>1))  ...  in  P 

assert  (a0®*|)©(jr®al)*(b0®al)®(x®*|)  fn  P  , 

where  the  operator  ©  Is  commutative  and  associative,  operator  9  satisfies 
(a®6)®c=(a®c)®4> ,  and  (a©6)®c«(a®c)©(69c) .  The  various  relation  rules  are  related  to 
optimization  and  extension  techniques,  where  the  desired  relation  Is  given  along  with  the 
assignments  to  one  of  the  variables,  and  the  proper  assignment  to  the  other  variable  is 
sought  (as  in  the  previous  chapter).  For  related  approaches  see  Caplain  [1076]  and 
German  [1978]. 


S.  Control  Rules 

Unlike  the  previous  rules  that  completely  ignore  the  control  structure  of  the  program, 
control  rules  derive  important  invariants  from  the  program  structure;  they  are  directly 
related  to  the  verification  rules  of  Hoare  [I860].  There  are,  for  example,  two  rules  to 
push  invariants  forward  In  a  loop.  The  forward  loop-exit  rule, 

loop  P' 

assert  a 
until  t 
L': 

P" 

repeat 

_ 

V\  assert  a,  -d 
L":  assert  a,  t 

reflects  the  fact  that  if  execution  of  a  loop  terminates  at  L"  ,  then  the  exit  test  t  must 
have  just  held,  while  if  the  loop  Is  continued  at  U  ,  the  exit  test  was  false.  Furthermore, 
any  relation  a  that  held  just  prior  to  the  test,  also  holds  immediately  after.  The  forward 
loop-body  rule, 


assert  6 
repeat 

L:  assert  aV|9 

states  that  for  control  to  be  at  the  head  of  a  loop,  at  L  ,  either  the  loop  has  just  been 
entered,  or  the  loop  body  has  been  executed  and  the  loop  is  being  repeated.  Therefore 
the  disjunction  aV/9  of  an  invariant  a  known  to  hold  just  before  the  loop  and  an  invariant 
0  known  to  hold  at  the  end  of  the  loop  body  must  hold  at  L  . 

Applying  the  first  rule  to  the  loop  In  the  Integer-division  program  Pn  yields  the 
invariant  r<d  at  £0  and  rid  at  the  head  of  the  loop  body: 

0 q.r )  :=  (0,  c) 

loop 

until  r<d 
assert  rid 
(q.r)  >  (q*  1 , r-d) 

repeat 

£,:  assert  r<d  . 


To  propagate  invariants,  such  as  rid ,  past  assignment  statements,  we  have  a 
forward  assignment  rule, 

assert  a(x,y) 
x  >  f(x,y) 

L\ _ 

L:  assert  a (f~(x,y),y)  , 

where  f"  Is  the  inverse  (assuming  that  there  is  an  inverse)  of  the  function  /  in  the  first 
argument,  i.e.  f'(f(x,y),  y)*x  .  By  using  the  inverse  function  /'  ,  the  value  of  x  prior  to 

the  assignment  may  be  expressed  in  terms  of  the  current  value  of  x  as  f(x,y) .  Thus,  if 
the  relation  o(x,  y)  held  before  the  assignment  to  x ,  then  after  the  assignment 

<*(f~(x,y),  y)  holds.  Even  if  there  Is  no  Inverse  function,  variants  of  this  rule  may  often  be 
used  to  glean  some  useful  information. 
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In  our  example,  since  the  first  loop-body  assignment  q:*q*  I  does  not  affect  any 
variable  appearing  In  the  Invariant  rid ,  the  invariant  is  pushed  forward  unchanged.  To 
propagate  rid  past  the  second  assignment,  r:«r-d ,  we  replace  r  by  the  Inverse  of 
r-d  ,  that  is  r*d  ,  yielding  r*did  ,  or 

assert  riO  , 

at  the  end  of  the  loop  body. 

We  have  an  assignment  axiom 

x  a 
assert  x*a  , 

where  the  expression  a  must  remain  constant  during  execution  of  the  assignment;  in 
other  words,  it  may  not  contain  x  .  This  axiom  gives  us  the  invariant 

assert  r=c 

prior  to  entering  the  loop.  Thus,  by  the  second  rule  for  loops,  the  forward  loop-body,  we  get 
the  loop  Invariant 

L0:  assert  r»eVr£0  . 

Since,  by  the  Input  specification  OSe  ,  the  first  disjunct  implies  the  second,  this  invariant 
simplifies  to 

L„;  assert  ri 0  . 

To  generate  invariants  from  a  conditional  test,  we  have  a  forward  test  rule: 

assart  a 

if  t  than  L'\ 

P' 

else  L": 

P" 

_ fi _ 

l'\  assart  o,  t 
L":  assart  a,  -<t  . 

That  is,  for  the  then-branch  to  be  taken  t  must  be  true,  while  for  the  else-branch  to  be 
taken  it  must  be  false;  furthermore,  any  a  that  held  before  the  test,  also  holds  after. 
Once  Invariants  have  been  generated  for  the  two  branches,  they  are  pushed  forward  by 
the  forward  branch  rule : 


.ft 
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if  t  then  P' 

assert  a 
else  P" 

assert  /8 
fi 

L: _ 

L:  assert  ctV0  . 

it  states  that  for  control  to  be  at  the  point  after  the  conditional  statement,  one  of  the  two 
branches  must  have  been  traversed. 

The  following  forall  rule  is  valuable  for  programs  with  universally-quantified  output 
specification.  Given  a  loop  invariant  e(x)  at  L  containing  the  integer  variable  (or 
expression)  x  and  no  other  variables,  check  if  x  Is  monotonically  increasing  by  one.  If  it 
is,  then  we  have  as  a  loop  invariant  at  L  that  a  still  holds  for  all  intermediate  values 
lying  between  the  initial  and  current  values.  That  Is 

assert  x-a,  xeZ 
loop  L :  assert  a(x) 

P 

assert  x*x6+ 1 
repeat 

L :  assert  (VfeZ)(a<f^x)a(f)  , 

where  a  is  an  integer  expression  with  a  constant  value  in  P  and  xL  is  the  value  of  x 
when  last  at  L  .  (This  rule  is  similar  to  the  universal-quantification  technique  for  arrays  in 
Katz  and  Manna  [1073].)  The  forall  rult  may  be  broadened  to  apply  when  x  is  increasing 
by  an  amount  other  than  1  ,  or  for  a  decreasing  x  . 


4.  Schematic  Rules 

In  this  subsection,  we  shall  Illustrate  how  the  control  rules  may  be  used  to  derive 
annotation  rules  for  program  schemata. 


Consider,  for  example,  the  following  single-loop,  single-conditional,  program  schema: 


t-, . 


►A.  > 

... 


P*:  begin  comment  single-loop  schema 
z  :=  c 

loop  L*:  assert  .  .  . 
until  t(z) 
z  :«  /(z) 

if  s(z)  then  z  :=  g(z)  else  z  :> 
repeat 
end  . 


h(z)  fi 


We  shall  assume  that  the  inverse  functions  /" ,  g~  ,  and  h~  are  available  whenever 
required  by  the  rules. 

The  assignment  axiom,  applied  to  the  initial  assignment  z:*c  yields  the  invariant 
assert  z=c 

before  the  loop.  The  forward  loop-exit  rule  generates  the  invariant  ~*{z)  at  the  head  of 
the  loop  body,  Immediately  after  the  until-clause,  and  then  the  forward  assignment  rule 

gives  - <t(f'(z ))  preceding  the  conditional.: 
assert  ->r(/"‘(z)) 

if  j(z)  then  z  :■  g(z)  else  z  :»  h(z)  fi  . 

The  forward  test  rule  propagates  that  invariant  forward,  adding  j(z)  at  the  head  of  the 
then-clause,  and  -v(z)  at  the  head  of  the  else-clause: 


if  j(z) 


then  assert  ~t(J~{z)),  s{z) 
z  g[z) 

else  assert  -v(z) 

z  :■  Hz) 

fi  . 


By  pushing  -d(f"(z))  and  s(z)  through  the  then-branch  assignment  z:*g(z) ,  end 
~>t(f~{z))  and  -vj(x)  through  the  else-branch  assignment  z:>A(z) ,  we  get 

if  j(z)  then  z  :■  g(z) 

assert  -4(f~{g~(z))),  s(g~(z)) 
else  z  :•  A(z) 

assert  -*V“(A'(z))),  -v(h’(z)) 

fi  . 


P 

>  i 
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Combining  the  invariants  from  the  two  different  paths  —  using  the  forward  branch  rule  —  one 
gets 


assert  A  ^‘(*»]  V  [-V(r(A'(*»>  A  -u(A-(z))] 

after  the  conditional,  at  the  end  of  the  loop  body. 

The  forward  loop-body  rule  expressed  the  fact  that  if  control  Is  at  the  head  of  a  loop, 
either  the  loop-initialization  Invariant  or  the  loop-body  invariant  must  hold.  Applying  this 
rule  to  our  schema 

assert  z-c 

loop  L*:  assert  .  .  . 
until  f(z) 
z  :=  /<z) 

if  s(z)  than  z  :=  g(z)  else  z  :*  A(z)  fi 

assert  [-./(/"<*'<*>»  A  *(*'<*»]  V  [-r(/“(A'(z)))  A  -v(A'(z))] 

repeat 

we  derive  the  loop  invariant 

L*:  assert  z=c  V  [-tfV(f”(z)))Ai(f*(z))]  V  [-<f(/“(A'(z)))A-y(A'(z))] 

This  loop  invariant  embodies  two  facts  about  the  control  structure  of  this  schema: 

•  Whenever  control  is  at  L*  ,  either  the  loop  has  Just  been  entered,  or  the  loop-exit 
test  was  false  the  last  time  around  the  loop.  That  is, 

L*:  assert  z=c  V  ->t[f~(f{z)))  V  -4{f~{h'{i)))  . 

The  first  disjunct  is  the  result  of  the  Initialization  path;  the  second  states  that  the  exit 

test  was  false  for  the  value  of  z  when  L*  was  last  visited,  assuming  control  came  via 
the  then-path  of  the  conditional;  the  third  disjunct  says  the  same  for  the  case  when 
control  came  via  the  else-path. 

•  Whenever  control  is  at  L*  ,  either  the  loop  has  Just  been  entered,  or  the  conditional 
test  was  true  the  last  time  around  and  the  then-path  was  taken,  or  the  test  was  false 
and  the  else-path  was  taken.  That  is, 

L*\  assert  z»c  V  i(g~(z))  V  -vW(z))  . 


As  another  simple  example,  consider  the  loop  schema 
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z  :=  0 

loop  L: 

until  r(z) 
z  :»  z+1 

repeat 

£:  . 


By  the  label  axiom 

L :  assert  x=xL  , 


we  get 

L:  assert  z=zL 

Thus,  we  can  easily  derive  the  following  invariants: 

z  :=  0 

assert  z= 0 
loop  L:  assert  z=z( 
until  t(z) 
z  :=  z+1 

assert  z-l=zL,  — 
repeat 

E:  assert  t(z)  . 

Now,  by  the  forward  loop-body  rule  we  can  derive  the  invariant 
L :  assert  z=0V-»f(z-l) 
and  by  the  forall  rule  ,  we  get 

L:  assert  (Vf€Z)(OSfSz)f«OV-K(r-l))  . 

This  simplifies  to 

L:  assert  (VfeN)(r<z)-<(f)  ; 
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combined  with  the  invariant  t(z)  that  holda  at  £  ,  it  implies  that  the  final  value  of  z  Is 
the  minimum  nonnegative  integer  satisfying  the  predicate  t : 

E:  assert  z={min  feNMf)  . 


5.  Heuristic  Rules 

In  contrast  with  the  above  rules  that  are  algorithmic  in  the  sense  that  they  derive 
relations  that  are  guaranteed  to  be  invariants,  there  is  another  class  of  rules,  heuristic 
rules,  that  can  only  suggest  candidates  for  Invariants.  These  candidates  must  be  verified. 

As  an  example,  consider  the  following  conditional  heuristic 

if  t  then  P' 

assert  a 
else  P" 

assert  8 

n 

La _ 

L.  suggest  a,  0  . 

Since  we  know  that  a  holds  If  the  then-path  P'  is  taken,  while  6  holds  if  the 
else-path  P"  is  taken,  clearly  their  disjunction  aV0  holds  at  L  in  either  case  (that  was 
expressed  in  the  forward  branch  rule).  However,  since  in  constructing  a  program,  a 
conditional  statement  is  often  used  to  achieve  the  same  relation  in  alternative  cases  (cf. 
the  conditional  synthesis  rule,  page  93),  it  is  plausible  that  a  (or,  by  the  same  token,  8  ) 
may  hold  true  for  both  the  then-  and  el£e-paths. 

As  mentioned  earlier,  the  output  specification  and  user-supplied  assertions  are  the 
initial  set  of  candidates.  Candidates  are  propagated  over  assignment  and  conditional 
statements  using  the  same  control  rules  as  for  Invariants.  The  top-down  heuristic, 

assert  a 

loop  L : 

until  t 
P 

repeat 

suggest  7 

fact  y  when  a 


L:  suggest  7  , 


may  be  used  to  push  a  candidate  (or  invariant)  7  backwards  into  a  loop.  Though  f:>7 
(i.e.  -itYY  )  would  be  a  sufficiently  strong  loop  invariant  at  L  to  establish  7  upon  loop 
exit,  the  heuristic  suggests  a  stronger  candidate,  7  itself,  at  L  .  Since  a  necessary 
condition  for  7  to  be  an  invariant  is  that  it  hold  upon  entrance  to  the  loop,  the  second 
antecedent  of  the  rule  requires  that  the  invariant  a  before  the  loop  imply  that  7  holds. 
The  idea  underlying  this  heuristic  is  that  an  iterative  loop  is  constructed  in  order  to 
achieve  a  conjunctive  goal  by  placing  one  conjunct  of  the  goal  in  the  exit  test,  and 
maintaining  the  other  invariantly  true  (cf.  th e  forward  loop  synthesis  rule,  page  97). 

Wegbreit  [1974]  and  Katz  and  Manna  [1976]  have  suggested  a  more  general  form  of 
these  two  heuristics: 

L:  assert  aV| 9 
L:  suggest  a,  ft  . 

However,  as  they  remark,  this  heuristic  should  not  be  applied  indiscriminately  to  any 
disjunctive  Invariant.  We  would  not,  for  example,  want  to  replace  all  occurrences  of  an 
invariant  x20  with  the  candidates  x>0  and  x=0 .  Special  cases,  such  as  the  above 
conditional  and  top-down  heuristics  are  needed  to  indicate  where  the  strategy  is  relatively 
likely  to  be  profitable. 

Returning  to  our  integer-division  example 


1  Po- 

begin,  comment  Integer-division  program 

~ 1 

1 

Bj  assert  ccN,  rfeN+i 

1 

(f.r)  :*  (0,c) 

1 

loop  L0:  assert  .  .  . 

1 

until  r<d 

1 

( q,r )  :=  1 ,  r-d) 

1 

repeat 

1 

£0:  suggest  qic/d,  c/d<q*  1,  qtt,  r*c-q>d 

I 

end  , 

1 _ 

_ i 

the  top-down  heuristic  suggests  that  of  the  candidates 

£0:  suggest  qSc/d,  c/d<q+ 1,  fcZ,  r*c-q»d  , 


those  that  hold  upon  entering  the  loop  —  when  q*0  and  r«e  —  are  also  candidates  at  L„ . 
They  are 
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Lt:  suggest  quid,  qeZ,  r*c-q*d  . 

The  remaining  candidate  at  £, ,  c/d<q+ 1  ,  does  not  necessarily  hold  for  q* 0  . 

Each  candidate  must  be  checked  for  invariance:  It  must  hold  for  the  loop-initialization 
path  and  must  be  maintained  true  around  the  loop.  Of  the  three  candidates  at  L0 ,  the  last 

two,  qeZ  and  r=c-q>d  ,  have  already  been  shown  to  be  global  invariants.  To  prove  that 
the  first,  quid ,  is  a  loop  Invariant  at  Lt ,  we  first  try  to  show  that  it  is  true  when  the 
loop  is  entered,  i.e.  that 

0 Uld  . 

The  truth  of  this  condition  follows  from  the  input  specifications.  Then  we  try  to  show  that 
if  quid  is  true  at  Lg  and  the  loop  is  continued,  then  quid  holds  when  control  returns  to 
L0 ,  I.e. 

q<cld  A  rid  o  q*l<c/d  . 

This  condition,  however,  is  not  provable.  Nevertheless,  we  can  show  that  quid  is  an 
invariant  by  making  use  of  the  global  Invariant  r=c-q*d  .  Substituting  c-q*d  for  r  in  rid 
yields  c-q-did  ;  it  follows  that  the  above  Implication  holds  and  quid  is  an  invariant  at 
L0 .  Thus,  while  an  attempt  to  directly  verify  the  candidate  qU/d  failed,  once  we  have 

established  that  n=c-q'd  is  an  Invariant,  we  can  also  show  that  quid  is  an  invariant. 

Indeed,  in  general  there  may  be  insufficient  information  to  prove  that  a  candidate  is 
invariant  when  it  Is  first  suggested,  and  only  when  other  Invariants  are  subsequently 
discovered  might  it  become  possible  to  verify  the  candidate.  Therefore,  candidates  should 
be  retained  until  all  invariants  and  candidates  have  been  generated.  Unproved  candidates 
are  also  used  by  the  heuristics  to  generate  additional  candidates.  For  example,  the 
top-down  heuristic  uses  the  as  yet  unproved  candidate  7  to  generate  the  loop  candidate 
7  at  t. 

Another  heuristic,  valuable  for  loops  with  universally  quantified  output  invariants,  is 
the  generalization  heuristic  rule 

assert 

loop  L:  suggest  a(x,y) 

P 

assert 

_ repeat _ 

L:  suggest  (Vf€{a,/(«),/V(a)) . x})a(t,y)  . 
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Given  •  loop  candidate  a(x,y) ,  we  determine  the  set  of  values  that  the  variable  x  takes 
on.  Then  we  have  as  a  new  candidate  for  a  loop  invariant  that  a  still  holds  for  all  the 
Intermittent  values  between  the  Initial  value  a  and  the  current  value  x  .  For  example,  if 
aeZ  and  /(x)-x+ 1  ,  then  we  get  the  candidate 

L:  suggest  (Vf€Z)(a£f£x)a(f ,})  . 

This  is  a  candidate  and  not  an  Invariant  since  the  program  segment  P  may  vary  the  value 
of  y  in  such  a  way  as  to  destroy  the  relation  a(x,y)  for  previous  values  of  x  . 

Note  that  a  candidate  invariant  must  sometimes  be  replaced  by  a  stronger  candidate 
In  order  to  prove  invariance.  This  is  analogous  to  other  forms  of  proof  by  induction,  where 
It  is  often  necessary  to  strengthen  the  desired  theorem  to  carry  out  a  proof.  The  reason 
Is  that  by  strengthening  the  theorem  to  be  proved,  we  are  at  the  same  time  strengthening 
the  hypothesis  that  Is  used  in  the  inductive  step.  We  could  not,  for  example,  directly 
prove  that  the  relation  (rid)V(r=c-q-d)  is  a  loop  invariant  (that  is  the  necessary  condition 
for  r^c-q-d  to  hold  after  the  loop),  since  this  candidate  is  not  preserved  by  the  loop,  i.e. 

[  rid  V  r*c-q>d  ]  A  rid  3  [  r-did  V  r-«f=c-(g+l)*rf  ] 

Is  not  provable.  On  the  other  hand,  we  can  prove  that  the  stronger  relation  r=c-?-rf  is  an 
invariant,  since  we  have  a  stronger  hypothesis  on  the  left-hand  side  of  the  implication; 
that  is, 

r=c-q*d  A  rid  3  r-d=c-(q*\)'d 

can  be  proved.  Clearly,  once  we  establish  that  r*c-q‘d  Is  an  invariant,  it  follows  that 
(rfcd)V(r=c-f«<f)  also  Is. 

Various  specific  methods  of  strengthening  candidates  have  been  discussed  in  the 
literature  (Wegbreit  [1074],  Katz  and  Manna  [1976],  Moriconi  [1974]  and  others);  they 
are  closely  associated  with  methods  of  "top-down"  structured  programming.  Related 
techniques  are  used  by  Greif  and  Waldinger  [1974]  and  Suzuki  and  Ishihata  [1977].  Also 
the  candidates  that  Basu  and  Misra  [1976]  and  Morris  and  Wegbreit  [1977]  derive,  using 
the  subgoal -induction  method  of  verification,  fall  into  this  class. 


6.  Counters 

A  useful  technique  for  proving  certain  properties  of  programs  is  the  augmentation  of  a 
program  with  counters  of  various  sorts.  For  example,  by  initializing  a  counter  to  zero  upon 
entering  a  loop  and  incrementing  it  by  one  with  each  Iteration,  the  value  of  the  counter  will 
Indicate  the  number  of  times  that  the  loop  has  been  executed.  Then,  relations  between 
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the  program  variables  and  the  counter  can  be  found.  By  deriving  upper/iower  bounds  on 
the  counter,  the  termination  of  the  loop  may  be  proved  and  time  complexity  analyzed. 

As  a  simple  example,  reconsider  our  (now  annotated)  division  program 

f - 1 

|  assert  cell,  rfeN+l,  geN,  r*c-q*d  ia  | 

|  P0:  begin  comment  integer -division  program  | 

|  (?, r)  :=  (0,<)  | 

|  loop  Lo:  assert  qic/d  j 

|  until  r<d  | 

|  (q.r)  :=  (q* 1 ,  r-d)  | 

j  repeat  j 

j  £„:  assert  rid  \ 

j  end  j 

i _ » 

The  variable  q  is  incremented  by  1  with  each  loop  iteration  and  is  initialized  to  0  ;  thus, 
it  serves  as  a  loop  counter.  Since  the  loop  invariant  qic/d  gives  an  upper  bound  on  the 
value  of  the  counter,  and  the  counter  is  incremented  with  each  loop  Iteration,  the  loop 
must  terminate.  Since  the  output  invariant  rid  and  global  invariant  r*c-q'd  yield  a  lower 
bounds  on  the  value  of  the  counter,  one  can  determine  the  total  number  of  loop  iterations. 

Examples  of  the  use  of  counters  for  proving  termination  have  appeared  in  Katz  and 
Manna  [Dec.  1976]  and  luckham  and  Suzuki  [1977].  Loop  counters  may  also  be  used  to 
discover  relations  between  variables  by  solving  first-order  difference  equatibns.  (See,  for 
example,  Elspas  [1974]  and  Katz  and  Manna  [1976];  Netzer  [1976]  applies  this 
technique  to  recursive  programs).  Related  work,  making  use  of  a  small  collection  of 
"loop-plans"  to  decompose  program  loops,  may  be  found  in  Waters  [1977].  McCarthy  and 
Talcott  [1978]  distinguish  between  extensional  properties  of  programs  that  depend  only  on 
the  function  computed  by  the  program  and  intentional  properties,  such  as  space  and  time 
requirements,  that  may  be  made  explicit  in  derived  programs  containing  counters. 


In  the  following  section,  we  demonstrate  how  two  nontrivial  programs  can  be 
annotated  using  the  annotation  rules.  These  examples  are  taken  from  the  program 
annotation  literature  in  order  to  demonstrate  the  power  of  our  approach. 
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3.  EXAMPLES 

Our  first  example  is  the  annotation  of  a  program  intended  to  divide  two  real  numbers. 
The  second  example  Is  a  program  with  nested  loops  designed  to  sort  an  array. 


Example  1>  Real  Division. 

Consider  the  following  program  P,  purporting  to  approximate  the  quotient  c/d  of  two 
nonnegative  real  numbers  c  and  d  ,  where  c<d  .  Upon  termination,  the  variable  q  should 
be  no  greater  than  the  exact  quotient,  and  the  difference  between  q  and  the  quotient 
must  be  less  than  a  given  positive  tolerance  t .  The  program,  with  its  specifications 
included  as  assertions,  is: 

I - 1 

|  Pt:  begin  comment  real-division  program  I 

|  6,:  assert  0<c<d,  0<e  | 

|  (q.qq.r.rr)  :•  (0,0,1  ,d)  | 

I  loop  L,:  assert  ...  j 

|  until  r<«  | 

|  if  qq*rr<c  then  (q.qq)  :»  (q*r,  qq+rr)  fi 

|  (r.rr)  :«=  (r/2,rr/2)  j 

|  repeat  j 

j  £,:  suggest  qic/d,  c/d<q*e  { 

|  end  .  | 

I - 1 

Our  goal  Is  to  find  loop  Invariants  at  Lx  in  order  to  verify  the  output  candidates  at  £( .  In 
our  presentation  of  the  annotation  of  this  program,  we  first  apply  the  assignment  rules  and 
then  the  control  rules  combined  with  a  heuristic  rule. 


I.  Assignment  Rules 

As  a  first  step,  we  attempt  to  derive  simple  invariants  by  ignoring  the  control 
structure  of  the  program,  and  considering  only  the  assignment  statements.  This  will  yield 
global  Invariants  that  hold  throughout  execution. 

We  first  look  for  range  Invariants  by  considering  all  assignments  to  each  variable.  For 
example,  since  the  assignments  to  r  are 


w*.  » 


^r-.-'l.-.  J lJ-*fC-«'.’.vW.' 


ik—. 
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r  :=  I  r  :«  r/2  , 
we  can  apply  the  multiplication  rule 

x  :■  «#  x  :*  *•«,  x  :•  x*at  ...  in  P 
assert  *€<»,•«,**•«,• ...  in  P. 

Taking  i  for  a„  and  1/2  for  a, ,  we  derive  the  global  Invariant 

assert  rel/2N  in  P,  .  CD 

In  other  words,  r=l/2n  for  some  nonnegative  integer  n  .  From  this  It  is  possible  to  derive 

lower  and  upper  bounds  on  r  ,  i.e.  0<rs  I  ,  since  1  when  n=0 ,  while  r- 1  /2n 
approaches  0  as  n  grows  large. 

Similarly,  applying  the  multiplication  rule  to  the  assignments  to  rr  , 
rr  :*  d  rr  :*  rr/ 2  , 

yields 

assert  rred/ 2N  in  P,  .  (2) 

Since  we  are  given  that  dX) ,  it  follows  that  (XrrSrf  . 

The  assignments  to  q  are 
q  :*  0  q  :■  q+r  . 

Since  we  know  (D  re  1/2** ,  these  assignments  may  be  interpreted  as  the  nondeterministic 
assignments 

q  :c  0  q  :e  f»l/2** 

Using  the  set-addition  rule  <> 

x  :e  S0  x  :c  x+S ,  *  :c  x*St  ...  in  P 

assert  ...  in  P  , 

we  conclude 

assert  ?e£l/2M  in  P,  . 


This  invariant  states  t|iat  q  Is  a  finite  sum  of  elements  of  the  form  l/2n  ,  where  n  is 
some  nonnegative  integer.  Since  for  any  two  such  elements,  one  Is  a  multiple  of  the  other, 

It  follows  that  the  sum  is  of  the  form  m/2n  ,  where  m,  ncN  s 

assert  ?eW/2W  in  P ,  O) 

(i.e.  q  is  a  dyadic  rational  number). 

From  (2)  rrcd/2**  and  the  assignments 
qq  :*  0  qq  :«  qq+rr  , 
we  get  by  the  same  set-addition  rule 

assert  qqed'E  l/2w  in  Pt  , 
or 

assert  qqzd-W 2W  in  Pt  .  (4) 

The  above  four  invariants  give  the  range  of  each  of  the  four  program  variables.  Now 
we  take  up  relations  between  pairs  of  variables  by  considering  their  respective 
assignments.  Consider,  first,  the  variables  r  and  rr  .  Their  assignments  are 

(r.rr)  :«  (l.rf)  (r,rr)  :«  (r/2,rr/2)  . 

Each  time  one  is  halved,  so  Is  the  other;  therefore,  the  proportion  between  the  initial 
values  of  r  and  rr  Is  maintained  throughout  loop  execution.  This  is  an  instance  of  the 
multiplication-relation  rule 

(x.j)  («„,»„)  (x,j)  :«  (x*utfi,yiA) 

_ (x,y)  :■  ...  in  P 

assert  xV&0ai«a^i*yai  In  P  , 

yielding  r  *  •<*  *  *  1 1  *rr 1  which  simplifies  to 
assert  rr«d*r  in  Px  . 


(5) 
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(The  rule  may  be  matched  with  the  assignments  in  the  following  manner:  Clearly,  the 
assignment  (ac  ,y)'Ma0,b0)  matches  with  (r,rr):«(l,d)  by  Instantiating  x,  y,  a,  and  6„ 
with  r  ,  rr  ,  I  ,  and  d  ,  respectively.  Substituting  these  values  In  the  second  assignment 
of  the  rule,  we  are  left  with  (r,  rr):«(r*uai,  rr*u*i)  to  match  with  (r,rr):=(r/2,rr/2) .  To 
match  fua i  =>  r/2  ,  divide  both  sides  by  r  ,  leaving  uai  ■»  1/2  .  This  in  turn  is  effected 
by  Instantiating  a,  ■*  1  and  u  =»  1/2  .  It  remains  to  match  rr*(l/2)*i  rr/ 2  ,  i.e. 
(1/2)* i  1/2  ,  and  6,  instantiates  to  1  .) 

The  assignments  to  q  and  qq  are 

iq.qq)  :•  (0,0)  (q,  qq)  :*  (q+r,qq+rr)  . 

Using  (6)  rr=rf»r  to  substitute  for  rr  in  the  assignment  qq:*qq*rr  ,  we  have 
(?,  qq)  >  (0,0)  (q,qq)  >  ( q+r.qq+d-r )  , 
which  Is  an  instance  of  the  addition-relation  rule 

(x.y)  >  (ao,  bj  (x,y)  :■=  (x+a,*u, 

(*,>)  :=  (*♦«,*», y+bfv)  ...  in  P 
assert  at-(y-b<shbf(x-al)  in  P  . 

Thus  we  have  the  global  Invariant  H?f-0)=<Kg-0) ,  i.e. 

assert  qq=d-q  in  P,  .  (6) 

In  all,  we  have  established  the  following  global  invariants: 

assert  re  1/2**,  rred/2**,  jeN/2**,  qq*.A'W 2**,  rr=rf*r,  qq-d*q  in  P,  . 


2.  Control  Rules 

So  far  we  have  derived  global  Invariants  from  the  assignment  statements,  Ignoring  the 
control  structure  of  the  program.  We  turn  now  to  local  Invariants  extracted  from  the 
program  structure. 


*v  > 
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By  applying  the  assignment  axiom 

x  :=  a 
assert  x-a 

to  the  multiple  assignment  at  the  beginning  of  the  program  we  get  the  local  invariant 
assart  q- 0,  qq=0,  r=l,  rr»d 
just  prior  to  the  loop.  The  loop  axiom , 

loop  P' 

until  t 
assert  ~>t 
P" 

repeat 
assert  t 

yields  r>e  at  the  head  of  the  loop  body  and  tie  at  Et .  Thus  far,  we  have  the  annotated 
program  segment 

assert  q* 0.  qq= 0,  r»l,  rr*d 
loop  L(:  assert  .  .  . 
until  r<e 
assert  r>e 

if  qq+rrsc  then  (q,qq)  :«  iq*r,qq*rr)  fi 
(r,  rr)  :*  ( r/2,rr/2 ) 

repeat 

£(:  assert  rie  . 


Applying  the  forward  test  rule, 


assert  a 
if  t  then 

L': 

else 

P' 
L "i 

fi 

P" 

L'\  assert  a,  t 
L"’.  assert  a,  ~<t  , 

to  the  conditional  statement  of  the  loop, 

if  qq+rric  than  (q,  qq)  >  iq*T,qq*rr)  fi 
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yields 

if  qq+rric  then  assert  r>t,  qq+rric 
(fl.jfl)  :*  (q+r,qq+rr) 
else  assert  r>t,  e<qq*rr 
t i  . 

Using  a  variant  of  the  forward  assignment  rult, 

assert  a(u,y) 

x  >  u 

L\ _ 

L:  assert  a(x,y)  , 

where  x  does  not  appear  in  a( f,  y) ,  the  assignment  of  the  then-branch  transform  the 
Invariant  qq+rrie  into  qqic  and  leaves  r>e  unchanged.  We  obtain 

if  qq+rrie  then  ( q.qq )  :*  (q*r,qq*rr) 
assert  r>t,  qqic 
else  assert  r>c,  e<qq*rr 
fi  . 


We  may  now  apply  the  forward  branch  rule 

if  t  then  P' 

assert  a 
else  P" 

assert  0 
fi 

L: _ 

L:  assert  aV/9  , 

to  the  two  possible  outcomes  of  the  conditional.  We  obtain  the  invariant 
assert  (r>*l\qqsc)  V  (r>#Ae<^trr)  , 
which  simplifies  to  just 
assert  r>* 


since  r>t  appears  in  both  disjuncts  while  qq*cVc<qq+rr  is  Implied  by  the  global  invariant 
(£  )  rr> 0  (  qqScVciqq  is  a  tautology,  and  If  rr  is  positive,  then  c<qq  implies  c<qq*rr  ). 
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By  application  of  tha  forward  assignment  rule 

assart  a(x,y) 
x  :■  f{x,y) 


L:  assart  <*(/“( x,y),y) 

to  tha  invariant  r>e  ,  we  pet 
assert  2*r>r 

at  the  end  of  the  loop.  By  applying  the  forward  loop-body  rule, 

assert  o 
loop  L: 

P 

assart  0 
repeat 

L:  assert  aV0  , 

taking  2 *r>*  for  0  ,  we  derive  the  loop  invariant 
Lx:  assart  (f  ff*OAr-lArr»<0  V  2*r>*  . 

In  order  to  simplify  the  presentation,  wa  shall  use  Instead  the  weaker 

L,:  assert  r«l  V  2 *r>r  .  (7) 


3.  Heuristic  Rules 

Recall  that  the  control  rules  gave  us 

if  qq+rr$c  then  iq,  qq)  :•  (q*r,qq*rr) 
assart  r>e,  qq$c 
alsa  assert  r>e,  c<qq*rr 
fi  , 

but  that  the  disjunction  of  qqic  and  c<qq*rr  turned  out  to  be  a  tautology.  The  conditional 
heuristic 


,*«*i*tikA3N* 
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if  t  then  P' 

assert  a 
else  P" 

assert  0 
fi 

L\ _ 

L:  suggest  a,  d 

suggests  that  each  of  the  two  Invariants,  qq<c  and  c<qq*rr  ,  that  hold  at  the  end  of  one 
of  the  conditional  paths,  may  be  an  invariant  for  both  paths.  So  we  have  the  candidate 

suggest  qq<e,  c<qq*rr 

following  the  conditional  and  preceding  the  assignment 
0.  rr)  :=  0/2,rr/2)  . 

By  application  of  the  forward  assignment  rule 

suggest  y(x,y) 
x  :=  fb.y) 

L\ _ 

L:  suggest  y{f~(x,y),y) 

to  the  two  candidates,  we  get 

suggest  qq<e,  c<qq*2>rr 
at  the  end  of  the  loop. 

Finally,  by  applying  the  forward  loop-body  rule, 

assert  a 
loop  L: 

P 

suggest  y 
repeat 

L:  suggest  aV7  , 
we  get  the  candidates 


L,:  suggest  (q=qq*Ohr*\Arr*d)Vqq$c,  (q*qq*0Ar*  I  t\rr=d)Vc<qq*2-rr  . 

Both  candidates  may  be  simplified,  since  their  first  disjunct  implies  their  second,  leaving 
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Lx:  suggest  qq<c,  c<qq*2-rr  . 

These  two  candidates  can  indeed  be  proved  to  be  invariants:  The  first  candidate,  qq<c  , 
derived  from  the  initialization  and  then-paths,  is  unaffected  by  the  else-path  which  leaves 
the  value  of  qq  unchanged.  Similarly,  the  other  candidate,  e<qq*2‘rr ,  derived  from  the 
initialization  and  else-paths,  is  maintained  true  by  the  then-path.  So  we  have  the  loop 
invariants 

L,:  assert  qq<c,  c<qq+2’rr  .  (8) 

Note  that  we  have  not  yet  made  any  use  of  the  candidates 
suggest  qic/d,  c/d<q+e  , 

suggested  by  the  output  specification.  For  completeness,  we  shall  apply  a  heuristic  to 
these  candidates,  though  no  new  invariants  wilt  be  derived.  The  top-down  heuristic  rule 

assert  a 
loop  L: 

until  t 
P 

repeat 
suggest  V 

fact  y  when  a 

L :  suggest  7 

* 

suggests  that  the  output  candidate  qic/d  may  itself  be  a  loop  invariant,  since  it  is  true 
upon  entering  the  loop.  Indeed  It  is  an  invariant  (it  is  implied  by  the  loop  invariant  qq<c 
and  the  global  invariant  qq=q*d  ).  On  the  other  hand,  the  second  output  candidate, 
c/d<q*e  ,  does  not  even  hold  for  the  initialization  path,  when  q* 0  . 

Since  there  are  no  assignments  between  the  loop  and  the  end  of  the  program,  all  the 
loop  Invariants  may  be  pushed  forward  unchanged,  and  hold  upon  termination.  The  output 
invariants  Include 

assert  (MV2t>#),  qqie,  c<qq*2>rr,  rit  .  (9) 

These  Invariants,  along  with  the  global  invariants 
assert  rr«<f*r,  qq*d-q  in  P,  , 

imply  qic/d  as  specified.  However,  they  do  not  imply  c/d<q*t ,  only  c/d<q+2'e  .  In  fact, 
our  program  as  given  Is  Incorrect.  In  another  chapter,  we  have  already  seen  how  such 
Invariants  mey  be  used  to  guide  the  debugging  of  the  progrem. 
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4.  Loop  Counters 

By  introducing  an  imaginary  loop  counter  n  —  initialized  to  0  upon  entering  the  loop 
and  incremented  by  1  with  each  iteration  —  one  may  derive  relation  between  the  program 
variables  and  the  number  of  iterations. 


The  extended  program,  annotated  with  some  of  the  invariants  we  have  already  found, 
is: 


r 


|  assert  rr=d>r,  qq=d-q,  re  1/2^,  rreN/2^  in 
j  Pt:  begin  comment  extended  real-division  program 
j  B,:  assert  0 <c<d,  0<e 

|  (q.qq.r.rr)  :=  (0,0,1  ,d) 

J  n  :=  0 

j  loop  L,:  assert  (r=lV2*r><),  qq<e,  c<qq*2m 

|  until  r<e 

j  if  qq*rrsc  then  ( q,qq )  :*  (q*r,qq*rr)  fi 

j  (r,rr)  :*  (r/2.rr/2) 

| 

|  repeat 

|  £,:  assert  (r=IV2v><),  qqie,  c<qq*2'rr,  rie 

I  end  . 

»  _ I 


Obviously,  we  may 

assert  neN  in  Pt  .  (10) 

For  the  variables  r  and  n  ,  we  have  the  assignments 
(r,n)  :=  (1,0)  (r,n)  :«  (r/2,  n+l) 

and  we  can  apply  the  linear  rule 

( x,y )  :■  (<*„,$„)  ( x,y )  :■  (at*x*9t,y*bt)  in  P 
assert  [x'(a|-l)+aJ]^fO|^o»[o(,*(e,-l)+at]^fa(?  in  P  . 

With  this  rule  we  get  the  global  invariant 

assert  [r«(l/2-l)+0],*(l/2)°-[l*(l/2-l)*0],*(l/2)n  in  Pt  . 
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which  simplifies  to 
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assert  r=!/2B  in  P,  (11) 

Applying  the  seme  rule  to  the  essignments 

(rr.n)  :*  (rf.O)  (rr.n)  :■  (rr/2.  !*♦!) 
we  deduce 

assert  rr=rf/2n  in  P,  .  (12) 

With  these  loop-counter  inverlants,  the  total  number  of  loop  iterations  as  a  function  of 
the  input  values  may  be  determined.  Using  (11),  we  can  substitute  l/2n  for  r  in  the 
loop  invariant  (7)  r=lV2*r>«  and  in  the  output  invariant  (9)  r<e  ,  and  get  l/2n= I V2/2”>r 
at  Lt  and  l/2nie  at  Et.  Taking  the  logarithm  (  e  is  positive),  we  have  the  upper  bound 

n=0  V  n<-logte*l 
and  lower  bound 
-log,e<n 

on  the  number  of  loop  iterations  n  .  Note  that  by  finding  a  loop  invariant  giving  an  upper 
bound  on  the  number  of  iterations,  we  have  actually  proved  that  the  loop  terminates. 

Combining  both  bounds  at  £,  gives  (assuming  n»0) 

-lt>g,ein<-logte+ 1  , 

or,  since  n  Is  an  Integer  (10),  it  is  equal  to  the  one  integer  lying  between  its  lower  and 
upper  bound  ~[log7e J  .  Thus  we  have  the  output  invariant 

assert  n*0  V  n=-|/o$.rJ  .  (13) 

Since  n  Is  the  number  of  times  the  loop  was  executed  before  termination,  we  have 
derived  the  desired  expression  for  the  time  complexity  of  the  loop. 


Example  St  Selection  Sort. 

The  previous  example  contained  only  one  loop  and  dealt  with  simple  variables.  As  a 
more  challenging  example,  we  annotate  an  array-manipulation  program  containing  nested 
loops.  The  program  is  intended  to  sort  the  array  A[0:n]  of  a*  I  elements  A[0]  , 
A[l ],...,  A[n]  in  ascending  sequence.  The  output  specification  can  therefore  be 
expressed  as 
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(Vf  )(OSf<n)Gf[f  ♦  I])  A  tafM[0:n])-6a*Ua  [0:n]) 

where  bag(A[0:n])*bag(AB  [0:n])  means  that  the  multiset  (bag)  of  elements  in  the  array 
segment  vf[0:n]  is  equal  to  the  multiset  of  elements  in  the  Initial  value  of  the  array  .. 
i.e.  A [0:n]  is  a  permutation  of  As  [0:n] .  The  program  is: 

I  I 

|  Pf:  begin  comment  selection-sort  program  | 

|  Bt:  assert  ncM  | 

j  i  :*=  0  I 

j  loop  Lt:  assert  ...  | 

|  until  tin  | 

|  P,:  begin  | 

J  (/.m.k)  *.=  (i+1,  | 

|  loop  L assert  ...  | 

j  until  )>n  | 

j  if  A[J]<m  then  (m.Jk)  :*=  (,<[/), j)  fi  j 

I  J  :■  J*'  I 

|  repeat  | 

I  :»  I 

j  end  j 

|  repeat  | 

|  £t:  suggest  (Vf )(0Sf<n)(^[f]^[f*I]),  fc*f(/f[0:n])=&ag(/4a  [0:n]).  | 

|  end  | 

i  -  - 1 


1 .  Assignment  Rules 

We  first  try  to  determine  the  range  of  the  program  variables.  The  variables  in  the 
program  P}  are  i  ,  j  ,  k  ,  m  ,  and  A  j  the  inner  loop  (the  program  segment  P , )  sets  the 
variables  j  ,  it  and  m  ,  and  leaves  i  and  A  unchanged. 

The  assignments  to  i  are 

i  :«=  0  i  :«  M  , 

which  by  the  addition  rule  gives  the  global  Invariant 

assert  in  Pt  .  (1) 
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The  assignments  to  j  are 
j  :*  f+l  j  :«  j+\  . 

Since  we  know  ieN ,  we  may  substitute  N  for  <  to  obtain  the  nondeterministic 
assignments 

j  :e  N+l  j  :e  j+1  , 

and  by  the  set-addition  rule  we  get  jcN+l+Sl  ,  which  simplifies  to 

assert  jell,  I ij  in  P}  .  (2) 

(Recall  that  these  global  invariants  only  hold  after  J:*i+i  is  executed  for  the  first  time.) 
Since  within  P,  the  value  of  i  is  unchanged,  It  may  be  regarded  as  constant.  We  can 
therefore  apply  the  addition  rule  to  the  assignments  to  j  ,  j:*i*l  and  J:=j+ 1  ,  obtaining 

assert  jet+l+N  In  P, 

and  consequently 

assert  i<j  in  P,  .  (3) 

The  assignments  to  k  are 

*  :■  i  k  >  j  . 

Using  (1)  and  (2)  to  substitute  N  for  f  and  J  ,  we  have 
fc  .:e  N  k  :c  N 
and  from  the  simple  set-union  rule 

x  :e  J#  x  :c  S,  in  P 
assert  xeSJJSt  in  P 

it  follows  that 

assert  kcN  in  Pt  .  (4) 

in  P, ,  as  we  have  seen,  i  is  constant  end  Jel+I+H  ,  so  we  substitute  f+i+N  for  j  in 
the  assignments  to  k  to  obtain 

k  :e  i  k  :c  i+UN 

By  the  same  set-union  rule,  we  have  that  k  belongs  to  the  union  of  i  and  . 

Therefore  kcJ+N ,  and 


(6) 


assert  i<k  in  P %  . 

Finally,  for  m  we  have  the  assignments 
m  :*  A[i]  m  :«  A[j]  . 

Using  (1)  teN  and  (2)  jeN  to  substitute  M  for  i  and  J  ,  we  get 
m  :e  >f[N]  m  :e  >f[M]  . 

Thus,  by  the  set-union  rule,  we  obtain 

assert  m€^[N]  in  Pt  .  (6) 

In  the  following  subsections,  we  shall  apply  the  control  rules  and  heuristics  first  to  the 

Inner  loop  and  then  to  the  outer  loop. 


2.  Control  Rules  -  Inner  Loop 
The  inner  loop  of  the  program  is 

loop  L,:  assert  .  .  . 
until  j> n 

if  >f[/]<m  then  (m,  JO  :*  (A\j],j)  ti 

J 

repeat  . 

At  any  point  in  a  program,  the  disjunction  of  what  Is  known  from  the  paths  leading  to  that 
point  Is  an  Invariant.  We  shall  use  the  control  rules  to  obtain  loop  Invariants  at  label  L, , 
by  considering  the  three  paths  leading  to  L, :  the  Initialization  path  from  Lt  to  L. ,  the 
loop-body  path  from  JL,  to  L,  via  the  then-branch  of  the  conditional,  and  the  loop-body 
path  via  the  else-branch  of  the  conditional. 

From  the  Initialization  path,  we  have  upon  entering  the  Inner  loop 

Kn  A  pi* l  A  m«40  A  *■/  .  (7) 

The  conjunct  Kn  derives  from  the  negation  of  the  outer-loop  exit  test,  using  the  loop 
axiom 
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loop  P' 

until  t 
assort  ~v 

P" 

ropoat 

assort  t 

By  applying  the  assignment  axiom 

x  :«  a 

assert  x=a 

to  the  assignment  of  the  initialization  path 
{ j,m,k )  >  (i*l,A[i],i)  , 

we  obtain  the  three  invariants  j=i*l  ,  m=/f[i]  and  k*i . 

At  the  head  of  the  inner-loop  body,  we  have  the  invariant 
j<n  A  i=iL  A  A=AL  A  ]=jL  A  A  . 

where  xL  ,  for  some  variable  x  and  label  L  ,  denotes  the  value  of  x  when  control  was 
last  at  L  .  The  first  conjunct  Is  the  negation  of  the  exit  test  and  the  other  conjuncts, 
which  are  generated  at  L,  using  the  label  axiom, 

L:  assert  x=xL  , 

have  been  pushed  passed  the  exit  test  unchanged.  This  is  an  application  of  the  forward 
loop -exit  rule 

loop  P’ 

assert  a 
until  t 

L'\ 

P" 

repeat 


L assert  a,  ->t 
L":  assert  a,  t 


to  the  inner  loop.  After  executing  the  assignment  in  the  then-branch  of  the  conditional, 
we  know 
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IJ'PW 


jin  A  A  k»j  A  i-it}  A  A  j*jL,  . 

The  second  and  third  conjuncts  derive  from  the  assignments  (by  the  assignment  axiom);  all 
the  other  conjuncts  have  been  propagated  forward  by  the  forward  test  rule 

assart  a 

if  t  than  L'; 

/»' 

else  L": 

P" 

ft _ 

L assart  a,  t 
L":  assert  a,  -v 

and  forward  assignment  rule 

assert  a(x,y) 
x  :■  /(*,?) 

L: 


L:  assert  a(/~(x,j),j)  . 


After  the  (empty)  else-branch  of  the  conditional,  we  have 

jin  A  miA[j ]  A  M  A  A=A^  A  j^J^  A  *-*tj  A  . 

The  second  conjunct'  is  the  negation  of  the  conditional  test;  U  is  derived  from  the 
conditional  axiom 


if  t  then  assert  t 

P' 

else  assert  -tf 

P" 

ft  . 


Since  we  must  have  traversed  either  the  then-  or  else-branch,  we  know  by  the  forward 
branch  rule 

if  t  then  P' 

assert  a 
else  P" 

assert  <3 
ft 

L\ _ 

L:  assert  aV/9 
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that  after  the  conditional 

(  jin  A  m=jf[j]  A  k*j  A  i«it  A  A*At  A  j«Jt  ) 

V  (  jin  A  A  i*iL  A  >f»ylL  A  j*jL  A  A«ALj  A  n>mL  )  . 

Thus,  at  the  end  of  the  loop  body,  after  incrementing  j  by  I  ,  we  have  (by  the  forward 
assignment  rule ) 

(  j-l<n  A  m=if[/-l]  A  Jt=j- 1  A  Wtj  A  A*AL  A  )  (8) 

V  (  j-l<n  A  mSifQ-1]  A  i=fL<  A  A  j-\=jL  A  A  m«=m,  )  . 

Furthermore,  If  a  relation  o  holds  upon  entering  a  loop,  and  we  know  that  the  loop 
body  either  does  not  change  the  values  of  the  variables  in  a  ,  or  reachieves  a  for  the 
new  values  of  the  variables,  then  a  is  a  loop  invariant.  This  is  the  protected-invariant  rule 

assert  a(x) 
loop  L: 

P 

assert  a(x)Vx«xL 

repeat _ 

L:  assert  a(x)  . 

By  substituting  k  for  )- 1  in  the  first  disjunct  of  (8),  we  may  derive  kin  and  m=  /![*]. 
Thus,  at  the  end  of  the  loop  body  we  know  (*SnAroM[lk])  V  (A=AL  AJk=Jkt  Am=m<  ) .  This 

invariant  is  of  the  form  o(x)Vx*xL  ,  taking  a(x)  to  be  *SnAm=yf[Jk]  and  x  to  be  the 
variables  A  ,  k  and  m  .  The  first  disjunct  indicates  that  the  then-path  achieves  <*(x)  ; 
the  second  disjunct  states  that  the  else-path  leaves  A  ,  k  and  m  unchanged.  From 
invariant  (7)  preceding  the  loop,  we  can  derive  that  initially  kin  and  m*A[k] .  So  we 

have 

Lf:  assert  kin,  m*A[k]  .  (0) 

Similarly,  by  (8)  we  have  M.  for  both  loop-body  paths,  and  by  (7)  we  have  i<n  upon 
entering  the  loop.  Taking  a(l)  to  be  l<n  ,  we  get 

assert  i<n  .  (10) 

Disjoining  Invariant  (7)  of  the  Initialization  path  and  (6)  from  the  loop-body  path,  we 
get  the  following  Inner-loop  invariant  (by  the  forward  loop-body  rule  ): 

Ly  assert  (  i<n  A  j»i*  1  A  m-4[f]  A  k*t  ) 

V  (  j-lin  A  A  *-M  ) 

V  (  j-lin  A  ) 


(11) 
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+K  ¥  p. 


-  .... 


(The  conjuncts  refering  to  the  previous  value  of  a  variable  at  L,  have  been  removed.) 


Now  we  extract  the  "common  denominator"  of  the  disjuncts  in  (11)  arising  from  the 
different  paths.  The  relation  j-l£n  appears  in  the  second  two  disjunct s  and  is  implied  by 
the  two  conjuncts  i<n  and  J*i*i  of  the  first  disjunct,  so  we  get  the  invariant 


L,:  assert  j-lin  . 


(12) 


In  the  first  disjunct  of  (11)  we  have  ,  in  the  second  we  have  , 

while  In  the  third  we  have  ,  thus  for  all  paths 


L,:  assert  m£A[]-\] 


(13) 


Alternatively,  we  could  have  used  the  conditional  heuristic  rule,  rather  than  the 
protected-invariant  rule,  to  generate  these  assertions.  The  heuristic,  however,  would  have 
yielded  candidates  requiring  further  verification. 


1 
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3.  Centralization  Heuristic  -  Inner  Loop 

The  generalization  heuristic  rule  Is  particularly  valuable  for  loops  Involving  arrays: 
assert  x-a 

loop  L:  assart  a(x,y) 

P 

assert  *sxL+\ 
repeat 

L:  suggest  (V()(ai[ix)a(i,y)  . 

To  apply  this  heuristic,  reconsider  the  Inner-loop  invariant  (13)  a(j,  m) :  miA[j-l]  at  L, . 
Initially  j  is  i+l  ,  and  at  the  end  of  the  loop  body  j=jL  +1  ,  so,  as  an  invariant  candidate, 
we  try 

Ls:  suggest  (V{)(i+li{ij)(miA[t-l])  , 

which  we  shall  abbreviate  as  miA[i:j- 1],  Checking  the  candidate  for  the  then-  and 
else-paths  determines  that  it  is  in  fact  an  invariant;  thus,  we  have  for  the  inner  loop 

L}:  assert  .  (14) 

So  far  we  have  derived  the  following  Inner-loop  invariants 
L,:  assert  kin,  m=>4[*],  f<n,  j-lin,  . 

We  turn  now  to  consider  the  outer  loop. 


4.  Control  Rules  -  Outer  Loop 

Using  the  forward  loop-exit  rule  ,  the  invariants  at  L,  may  be  propagated  past  the  exit 
test  ]>n  ,  obtaining 

assert  kin,  Kn,  J-iin,  miA[l;j- 1],  J>n 

just  prior  to  the  assignment 

(AM,A[ill)  «<].»»,<♦!)  . 

Propagating  these  invariants  past  the  assignment,  we  get  the  following  invariants  at  the 
end  of  the  outer-loop  body; 

assert  kin,  <Sn,  ms<4[f:/-lj,  m»/4[i-l],  J- l»n  . 


(16) 
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The  Invariant  kin  Is  propagated  unchanged.  The  Invariant  i<n  becomes  i-Kn  after 
executing  i:*i+l  (by  the  forward  assignment  rule  ),  which  is  equivalent  to  iin  (since  both 
i  and  n  are  integers).  The  invariant  still  holds  after  assigning  ^[»]  to 

A[k]  ,  since  held  before  and  consequently  holds  now  as  well;  however, 

after  the  assignment  to  /f[i]  ,  it  becomes  m<^[i+l:j-i]  .  (To  propagate  invariants  over  an 
array  assignment,  there  is  a  forward  array-assignment  rule 

assert  a(A ,  z) 

A[yl  :»  /WW.  *) 

L\ _ 

L:  assert  a{asslgn(A,y,f~(A[y],z)),z)  , 

where  the  array  function  assigned, y,z)  yields  A  with  z  replacing  /f[j>] ,  and 
f~(f(A[y],  z),  z)-A[y]  .  This  rule  states  that  after  the  assignment  the  invariant  still  holds 

for  alt  the  elements  of  A  ,  save  >f[y] ;  it  also  holds  for  old  value  of  yfjji]  ,  f~(A[y],  z) .  In 
our  case,  the  old  value  of  /f[i]  cannot  be  reconstructed,  so  the  index  i  is  removed  from 
the  range  [f:/-l] .)  After  incrementing  i,  miA[i*l:j-l]  becomes  .  The 

assignment  A[i]:=m  generates  the  invariant  mM[i]  (by  the  assignment  axiom),  which 
becomes  after  incrementing  i .  Finally,  the  invariants  j-l<n  and  j>n  simplify 

to  J-l*n  (since  (2)  /eN  ). 

Clearly  upon  entering  the  outer  loop  (by  the  assignment  axiom ) 
i*0  . 

Thus,  by  the  forward  loop-body  rule  ,  we  have  the  outer-loop  invariant 
L,:  assert  i* 0  V  (ASnAiSnAmSif[f:/-l]Am«/f[f-l]A/-I=n) 
with  the  following  two  corollaries: 

L.:  assert  f«0V>4[M]</f[f:n]  (16) 

(the  second  disjunct  follows  from  ,  mM[i-I]  and  J-l*n  ),  and 

Lt:  assqrt  iin  (17) 

(since  1*0  implies  iin  for  neli ).  If  we  use  the  forward  loop-exit  rule  to  push  tin  past 
the  exit  test  iin  and  out  of  the  loop,  we  get  the  output  invariant  iin/\iin  at  £. ,  or. 


£,:  assert  l»n  . 


(18) 
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5.  Heuristics  -  Outer  Loop 

We  use  the  generalization  heuristic  rule  to  generalize  (16)  for  the  counter  i ,  where 
att,A)  is  i«OV>4[{-l]^i4[t:n]  .  Since  i  is  initially  0  ,  this  yields  the  candidate 

Lt:  suggest  (V{,)(OsfS/)(f-OV/f[f-l]Syf[f:n])  . 

This  is  equivalent  to 

L}:  suggest  W)(OSt<i)(A[r]£A[j>l:n]) 

and  states,  in  effect,  that  the  array  elements  jf[0:f-l]  are  sorted  and  that  they  are  all 
smaller  than  the  array  elements  W[i:n] .  Though  the  array  A  is  modified  along  the 
inner-loop  exit  path  by  the  assignments 

M[*].40>  :■  MM.w>  . 

using  iikin  and  (from  (6)  and  (9)),  invariance  along  that  path  can  be  shown. 

Since  iik  ,  the  assignment  to  >f[k]  cannot  destroy  the  order  of  jf[0:i-l]  ,  and 
clearly  an  assignment  to  /4[i]  has  no  effect.  Since  both  i  and  k  are  in  the  range 
[i:n]  ,  the  candidate  implies  that  jf[0:i-t]&i[i]  and  >l[0:i-l]£if[*]  .  So  assigning  yf[t]  to 
/([*]  does  not  affect  the  relation.  Lastly,  since  m  is  equal  to  the  previous  value  of 
A[k]  ,  assigning  that  value  to  A[i]  also  preserves  the  invariant.  The  effect  is  to 
exchange  the  values  of  ^[Jk]  and  yf[i]  . 

So  we  have  the  outer-loop  invariant 

L}:  assert  (vn(0<f<i)(/f[f]S/f[f ♦!:»«])  .  (19) 

This  may  be  pushed  out  of  the  loop  to  £f ,  and  with  (18),  i.e.  i*n  at  £. ,  implies  the  first 
conjunct  of  the  output  specification, 

(vr)(OSf<n)(/([f]S/ftf+l])  . 


The  top-down  heuristic  rule 
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assert  a 
loop  L: 

until  t 
P 

ropaat 
suggest  V 

fact  V  whan  a 
L:  suggest  1 

suggests  that  the  output  specification  bag{A[0:n])*bag(.AB  [0:n]) ,  which  is  obviously  true 

initially,  is  itself  a  candidate  at  L, .  Since  the  assignments  to  A  have  the  effect  of 
exchanging  the  values  of  A[k)  and  A[i]  ,  we  have  the  Invariant 

Lt:  assert  tagM[0:n])>ta{(<4t'[0:it])  .  (20) 


6.  Loop  Counters 

To  determine  the  time  complexity  of  this  program,  we  add  three  counters:  one  for  the 
outer  loop  (the  variable  i  la  effectively  an  outer-loop  counter),  one  for  the  inner  loop  (call 

It  n,  ),  and  a  third  to  sum  the  total  number  of  inner-loop  executions  (call  It  n*  ). 

The  extended  program,  annotated  with  some  of  the  more  important  loop  and  output 
assertions,  is: 


.  /  .  _  .. 


•i 


assert  ieH  in 

Pti  begin  comment  extended  selection-sort  program 
Bt :  assert  nekl 
l  :«  0 
n*  :=  0 

loop  Lt:  assert  iSn,  (Vf)(0sr<OU[f]^tf:n]),  bag(A[0:n])*bag(AB  [0:n]) 

until  ten 
assert  j,  kebi  in 
Ps:  begin 

:=  (t+1, 

n,  :=  0 

loop  L3:  assert  Kn,  Kjin*  1,  »<Jk<n,  m=^[t], 
until  j>n 

it  A\j]<m  then  (m,*)  :*  (A[j],j)  fi 

j 

ns  V1 

repeat 

n*  :=  n*+ns 

end 

repeat 


assert  i=n,  (Vf)(Osf<i)(>f[f]S/<[M:n]),  te^[0:n])>tef(^ff>[0:n]) 


By  the  addition-relation  rule  ,  we  can  easily  determine  that  n,  is  equal  to  j-i-1  ,  since 
J  Is  initialized  to  <+ 1  and  is  incremented  by  i  .  We  know  from  (16)  that  j-n*  I  when  the 
inner  loop  is  left,  and  it  follows  that  the  inner  loop  Is  executed  n-i  times  for  each 
outer-loop  iteration.  With  each  outer-loop  iteration,  i.e.  each  time  i  is  incremented  by  I  , 
the  total  number  of  inner-loop  iterations  Increases  by  n-i .  Using  the  following  quadratic 
rule 

C x,y )  :=  (a0,bt)  ( x,y )  :=  (x*ai,y*bl>x*bi)  in  P 
assert  (^-60)'2»o;2=(x-a„)-t6|*(x+a0-flf)+2’at»(fil+fc|*a(,)]  in  P  . 

and  taking  x  to  be  i  (initially  0  and  incremented  by  I  )  and  y  to  be  the  total  number 
of  inner-loop  executions  (incremented  by  n-i ),  it  may  be  determined  that 
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jy*2=/*[- !*(/-!  )+2*nJ  is  an  invariant.  (Recall  the  use  in  the  previous  chapter,  page  122,  of 
the  Inverse  of  this  rule.)  We  have  already  seen  that  upon  termination  f*n  ,  l.e.  the  outer 

loop  is  iterated  a  total  of  n  times.  Therefore,  when  the  outer  loop  is  left,  n*=n*(m-l)/2  , 
i.e.  the  total  number  of  inner-loop  executions  is  n*(n+l)/2  . 

In  a  sense,  annotating  programs  is  "putting  the  cart  before  the  horse"  as  the  whole 
tenor  of  "structured  programming"  stresses  developing  invariants  hand  in  hand  with  the 
code,  and  not  ex  post  facto,  as  annotation  implies.  Nevertheless,  the  development  of 
automatic  annotation  systems  is  important  for  a  number  of  reasons: 

•  The  real  world  contains  many  undocumented,  underdocumented,  and  misdocumented 
programs.  Even  annotated  programs  appearing  in  structured-programming  textbooks  have 
fallen  prey  to  error.  A  system  that  could  help  in  documenting  such  programs  would  clearly 
be  of  utility. 

•  Ultimately,  it  is  the  responsibility  of  the  programmer  to  guarantee  the  correctness  of 
his  product.  Even  if  he  uses  one  of  the  current  automatic  verification  systems,  he  is 
required  to  supply  most,  if  not  all,  of  the  necessary  invariant  assertions.  The  goal  of 
automatic  program  annotation  is  to  relieve  the  programmer  of  this  burden.  Agreed,  no 
present  or  foreseeable  system  is  likely  discover  very  subtle  invariants,  or  those  based  on 
deep  mathematical  theorems,  but  such  invariants  are  likely  to  be  uppermost  in  the 
programmer's  mind  anyway.  It  Is  the  "obvious"  invariants  that  he  finds  annoying  to  have  to 
formulate,  and  indeed  often  forgets,  causing  the  system  to  fail  in  its  proof.  For  example, 
the  invariant  kZn  is  crucial  for  the  correctness  of  the  selection  sort  program;  if  the 
programmer  omits  it,  the  verification  system  will  not  be  able  to  prove  correctness. 
Fortunately,  it  is  just  these  Invariants  that  an  automatic  annotation  system  would  find  easy 
to  derive.  Similarly,  invariants  needed  to  demonstrate  the  absence  of  runtime  errors  are 
usually  quite  simple,  and  there  has  already  been  some  success  in  providing  current 
verification  systems  with  the  capability  of  generating  them. 

•  Annotation  research  attempts  to  formalize  the  intuitions  that  lie  behind  well-designed 
programs;  thus,  it  has  important  implications  for  automatic  program  synthesis.  In  fact,  the 
same  rules  that  we  used  to  generate  invariants  from  programs  may  be  Inverted  to 
generate  programs  from  Invariants. 

•  Annotation  techniques  may  be  used  to  discover  Important  properties  of  programs  other 
men  correctness.  For  example,  one  may  wish  to  analyze  the  complexity  of  an  algorithm  or 
compere  the  efficiency  of  two  correct  programs.  This  is  not  usually  the  programmer’s 
>aapena»dtty.  Indeed,  even  simple  programs  are  sometimes  very  difficult  to  analyze  (cf. 
aemeaaen  end  Knuth  [1076]). 


> 


? 


175 


REFERENCES 


Balzer,  R.M.,  N.  Goldman,  and  D.  Wlla  [Aug,  1977],  Informality  in  program  specifications , 
Proc.  5th  Inti.  Joint  Conf.  on  Artificial  Intelligence,  Cambridge,  MA,  pp.  369-397. 

Basu  S.  and  J.  Misra  [March  1976],  Proving  loop  programs,  IEEE  Software  Engineering, 
vol.  SE-1,  no.  1,  pp.  76-86. 

Biermann,  A.W.  [1976],  Approaches  to  automatic  programming.  Advances  in  Computers, 
vol.  1 6,  Academic  Press,  New  York,  NY,  pp.  1  -63. 

Boyer,  R.S.,  B.  Elspas,  and  K.N.  Levitt  [Apr.  1976],  SELECT— a  formal  system  for  testing 
and  debugging  programs  by  symbolic  execution,  Proc.  Inti.  Conf.  on  Reliable  Software,  Los 
Angeles,  CA,  pp.  234-245. 

Boyer,  R.S.  and  J  S.  Moore  [Jan.  1976],  Proving  theorems  about  LISP  functions,  JACM,  vol. 
22,  no.  1,  pp.  129-144. 

Brown,  R.  [Oct.  1976],  Reasoning  by  analogy,  Working  paper  132,  Artificial  Intelligence 
Laboratory,  MIT,  Cambridge,  MA. 

Buchanan,  J.R.  and  D.C.  Luckham  [Mar.  1974],  On  automating  the  construction  of 
programs.  Memo  AIM-236,  Artificial  Intelligence  Laboratory,  Stanford  Univ.,  Stanford,  CA. 

Burstall,  R.M.  and  J.  Darlington  [Jan.  1977],  A  transformation  system  for  developing 
recursive  programs,  JACM,  vol.  24,  no.  1,  pp.  44-67. 

Caplain,  M.  [Apr.  1975],  Finding  invariant  assertions  for  proving  programs,  Proc.  Inti.  Conf. 
on  Reliable  Software,  Los  Angeles,  CA,  pp.  165-171. 

Chen,  T.W.  and  N.V.  Findler  [Dec.  1976],  Toward  analogical  reasoning  in  problem  solving  by 
computers,  Technical  report  115,  Dept,  of  Computer  Science,  State  Univ.  of  New  York, 
Buffalo,  NY. 

Conway  R.  and  D.  Gries  [1973],  An  introduction  to  programming:  A  structured  approach, 
Winthrop,  Cambridge,  MA. 

Dahl,  O.J.,  E.W.  Dijkstra,  and  C.A.R.  Hoare  [1972],  Structured  programming.  Academic 
Press,  New  York,  NY. 

Darlington,  J.  [July  1976],  Applications  of  program  transformation  to  program  synthesis, 
Colloques  IRIA  on  Proving  and  Improving  Programs,  Arc-et-Senans,  France,  pp.  1 33- 1 44. 

Darlington,  J,  and  R.M.  Burstall  [Mar.  1976],  A  system  which  automatically  improves 
programs,  Acta  Informatics,  vol.  6,  no.  1,  pp.  41-60. 

Dershowtiz,  N.  [1978],  The  evaluation  of  programs,  Ph.D.  Thesis,  Applied  Mathematics 
Dept.,  Weizmann  Institute,  Rehovot,  Israel. 

Dershowitz,  N.  and  Z.  Manna  [July  1976],  On  automating  structured  programming, 
Colloques  IRIA  on  Proving  and  Improving  Programs,  Arc-et-Senans,  France,  pp.  167-193. 

Dershowitz,  N.  and  Z.  Manna  [Nov.  1977],  The  evolution  of  programs:  Automatic  program 
modification,  IEEE  Software  Engineering,  vol.  SE-3,  no.  6,  np.  377-385. 


REFERENCES 


177 


Dershowit z,  N.  and  Z.  Manna  [May  1978],  Inference  rules  for  program  annotation,  Proc. 
3rd  Inti.  Conf.  on  Software  Engineering,  Atlanta,  GA,  pp.  168-167. 

Dershowitz,  N.  and  Z.  Manna  [Aug.  1979],  Proving  termination  with  multiset  ordttings, 
CACM,  vol.  22,  no.  8,  pp.  466-476. 

Deutsch,  L.P.  [May  1973],  An  interactive  program  verifier,  Ph.D.  thesis,  Univ.  of  California, 
Berkeley,  CA;  Memo  CSL-73-1,  Xerox  Research  Center,  Palo  Alto,  CA. 

Dijkstra,  E.W.  [1968],  A  constructive  approach  to  the  problem  of  program  correctness,  BIT,  vol. 
8,  no.  3,  pp.  174-186. 

Dijkstra,  E.W.  [1976],  A  discipline  of  programming,  Prentice  Hall,  Englewood  Cliffs,  NJ. 

Duran,  J.W.  [May  1976],  A  study  of  loop  invariants  and  automatic  program  synthesis,  Ph.D. 
thesis,  Memo  SESLTR-12,  Software  Engineering  and  Systems  Laboratory,  Univ.  of 
Texas,  Austin,  TX. 

Elspas,  B.  [July  1974],  The  semiautomatic  generation  of  inductive  assertion  for  proving 
program  correctness,  Interim  report,  Project  2686,  SRI  International,  Menlo  Park,  CA. 

Eve,  J.  [Sept.  1976],  On  computing  the  transitive  closure  of  a  relation,  Memo  CS-76-608, 
Computer  Science  Dept.,  Stanford  Univ.,  Stanford,  CA. 

Fikes  R.E.,  P.E.  Hart,  and  N.J.  Nilsson  [Winter  1972],  Learning  and  executing  generalized 
robot  plans.  Artificial  Intelligence,  vol.  3,  no.  4,  pp.  251-288. 

Floyd,  R.W.  [1967],  Assigning  meanings  to  programs,  Proc.  Symp.  in  Applied  Mathematics, 
vol.  19  (J.T.  Schwartz,  ed.),  American  Mathematical  Society,  Providence,  Rl,  pp.  19-32. 

Floyd,  R.W.  [Aug.  1971],  Toward  interactive  design  of  correct  programs,  Proc.  Information 
Processing  Cong.,  Ljubljana,  Yugoslavia,  pp.  7-10. 

Gerhart,  S.L.  [Apr.  1976],  Knowledge  about  programs :  A  model  and  case  study,  Proc.  Inti. 
Conf.  on  Reliable  Software,  Los  Angeles,  CA,  pp.  88-96. 

Gerhart,  S.L.  [July  1976],  Verification  operator  systems  and  their  application  to  logical  analysis 
of  programs,  Colloques  IRIA  on  Proving  and  Improving  Programs,  Arc-et-Senans,  France, 
pp.  209-221. 

Gerhart,  S.L.  and  L.  Yelowitz  [Dec.  1976],  Control  structure  abstractions  of  the  backtracking 
programming  technique,  IEEE  Software  Engineering,  vol.  SE-2,  no.  4,  pp.  286-292. 

German,  S.M.  [May  1974],  A  program  verifier  that  generates  inductive  assertions, 
Undergraduate  thesis,  Memo  TR- 19-74,  Harvard  Univ.,  Cambridge,  MA. 

German,  S.M.  [Jan.  1976],  Automating  proofs  of  the  absence  of  common  runtime  errors,  Conf. 
Rec.  6th  ACM  Symp.  on  Principles  of  Programming  Languages,  Tucson,  AZ,  pp.  105-1 18. 

German  S.M.,  and  B.  Wegbrelt  [Mar.  1976],  A  synthesizer  of  inductive  assertions,  IEEE 
Software  Engineering,  voi.  SE-1,  no.  1,  pp.  68-76. 

Gibb,  A.  [July  1961],  Algorithm  61:  Procedures  for  range  arithmetic,  CACM,  vol.  4,  no.  7,  pp. 
319-320. 


*’*  A 


176 


Green,  C.C.  [Oct.  1976],  The  design  of  the  PSI  program  synthesis  system,  Proc.  2nd  Inti.  Conf. 
on  Software  Engineering,  San  Francisco,  CA,  pp.  4*16. 

Greif,  1.  and  R.J.  Waldinger  [Apr.  1974],  A  more  mechanical  heuristic  approach  to  program 
verification,  Proc.  Inti.  Symp.  on  Programming,  Paris,  France,  pp.  83-90. 

Gries,  D.  [Nov.  1974],  On  structured  programming  -  A  reply  to  Semoliar,  CACM,  vol.  1 7,  no. 
1 1 ,  pp.  655-657. 

Harrison,  W.H.  [May  1977],  Compiler  analysis  of  the  value  ranges  for  variables,  IEEE 
Software  Engineering,  vol.  SE-3,  no.  3,  pp.  243-250. 

Hoare,  C.A.R.  [July  1961],  Algorithm  63:  Partition,  CACM,  vol.  4,  no.  7,  p.  321. 

Hoare,  C.A.R.  [Oct.  1969],  An  axiomatic  basis  of  computer  programming,  CACM,  vol.  12,  no. 
10,  pp.  576-680,  683. 

Huet,  G.  and  B.  Lang  [Nov.  1977],  Proving  and  applying  program  transformations  expressed 
with  second-order  patterns,  Report  266,  IRIA  Laboria,  Le  Chesnay,  France  (to  appear  in 
Acta  Informatlca). 

Jonassen,  A.T.  and  D.E.  Knuth  [June  1978],  A  trivial  algorithm  whose  analysis  isn't,  JCSS, 
vol.  16,  no.  3,  pp.  301-322. 

Kant,  E.  [Aug.  1977],  The  selection  of  efficient  implementations  for  a  high-level  language, 
Proc.  Symp.  on  Artificial  Intelligence  and  Programming  Languages,  Rochester,  My,  pp. 
140-146. 

Katz,  S.M.  [Sep.  1976],  Invariants  and  the  logical  analysis  of  programs,  Ph.D.  thesis, 
Welzmann  Institute  of  Science,  Rehovot,  Israel. 

Katz,.  S.M.  and  Z.  Manna  [Aug.  1973],  A  heuristic  approach  to  program  verification,  Adv. 
Papers  3rd  Inti.  Conf.  on  Artificial  Intelligence,  Stanford,  CA,  pp.  500-61 2. 

Katz,  S.M.  and  Z.  Manna  [Apr.  1976],  Towards  automatic  debugging  of  programs,  Proc.  Inti. 
Conf.  on  Reliable  Software,  Los  Angeles,  CA,  pp.  143-155. 

Katz,  S.M.  and  Z.  Manna  [Dec.  1976],  A  closer  look  at  termination,  Acta  Informatics,  vol.  6, 
no.  4,  pp.  333-362. 

Katz,  S.M.  and  Z.  Manna  [Apr.  1978],  Logical  analysis  of  programs,  CACM,  vol.  16.  no.  4, 
PP.  188-206. 

King,  J.C.  [July  1978],  Symbolic  execution  and  program  testing,  CACM,  vol.  19,  no.  7,  pp. 
386-391. 

Kling,  R.E.  [Aug.  1971],  Reasoning  by  analogy  with  applications  to  heuristic  problem  solving:  A 
case  study,  Ph.D.  thesis,  Stanford  Untv.,  Stanford,  CA 

Knuth,  D.E.  [Dec.  1974],  Structured  programming  with  go  to  statements,  Computing  Surveys, 
vol.  6,  no.  4,  pp.  261-301. 

Loveman,  D.B.  [Jan.  1977],  Program  Improvement  by  source-to-source  transformation,  JACM, 
vol.  24,  no.  1,  pp.  121-146. 

Luckham,  D.C.  and  J.R.  Buchanan  (July  1974],  Automatic  generation  of  programs 

J 


REFERENCES 


179 


containing  conditional  statements,  Proc.  Conf.  on  Artificial  Intelligence  and  the  Simulation  of 
Behaviour,  Sussex,  England,  p p.  102-126. 

Luckham,  D.C.  and  N.  Suzuki  [Mar.  1977],  Proof  of  termination  wit  Ain  a  weak  logic  of 
programs,  Acta  Informatics,  vol.  8,  no.  1,  pp.  21-36. 

McCarthy,  J.  and  C.  Talcott  [1978],  LISP  programming  and  proving,  Manuscript,  Artificial 
Intelligence  Laboratory,  Stanford  Univ.,  Stanford,  CA. 

Manna,  Z.  [June  1971],  Mathematical  theory  of  partial  correctness,  JCSS,  vol.  6,  no.  3,  pp. 
239-263. 

Manna,  Z.  and  R.J.  Waldinger  [Summer  1976],  Knowledge  and  reasoning  in  program 
synthesis,  Artificial  Intelligence,  vol.  6,  no.  2,  pp.  1 76-208. 

Manna,  Z.  and  R.J.  Waldinger  [Nov.  1977],  Synthesis:  Dreams  =>  Programs,  Memo 
AIM-302,  Artificial  Intelligence  Laboratory,  Stanford  Univ.,  Stanford,  CA. 

Manna,  Z.  and  R.J.  Waldinger  [May  1978],  The  logic  of  computer  programming,  IEEE 
Software  Engineering,  vol.  SE-4,  no.  3,  pp.  199-229. 

Misra,  J.  [July  1976],  Relations  uniformly  conserved  by  a  loop,  Colloques  IRIA  on  Proving 
and  Improving  Programs,  Arc-et-Senans,  France,  pp.  71-80. 

Misra,  J.  [Sept.  1978],  An  approach  to  formal  definitions  and  proofs  of  programming 
principles,  IEEE  Software  Engineering,  vol.  SE-4,  no.  6,  pp.  410-413. 

Moriconi,  M.S.  [Oct.  1974],  Towards  the  Interactive  synthesis  of  assertions.  Memo  ATP-20, 
Automatic  Theorem  Proving  Project,  Univ.  of  Texas,  Austin,  TX. 

Morris,  J.H.  and  B.  Wegbreit  [Apr.  1977],  Subgoal  induction,  CACM,  vol.  20,  no.  4,  pp. 
209-222. 

Netzer,  I.  [Apr.  1976],  Logical  analysis  of  recursive  programs.  Master's  thesis,  Weizmann 
Institute  of  Science,  Rehovot,  Israel. 

Nelson,. C.G.  and  D.  Oppen  [Apr.  1978],  Simplification  by  cooperating  decision  procedures. 
Memo  AIM-311,  Artificial  Intelligence  Laboratory,  Stanford  Univ.,  Stanford,  CA  (to 
appear  in  CACM). 

Sacerdoti,  E.D.  [Sept.  1976],  The  nonlinear  nature  of  plans,  Proc.  4th  Inti.  Joint  Conf.  on 
Artificial  Intelligence,  Tbilisi,  USSR,  pp.  206-214. 

Sagiv,  Y.  [Aug.  1976],  A  study  of  the  automatic  debugging  of  programs,  Master's  thesis, 
Weizmann  Institute  of  Science,  Rehovot,  Israel. 

Scherlis,  W.  [May  1974],  On  the  weak  Interpretation  method  for  extracting  program 
.  properties,  Undergraduate  thesis,  Harvard  Univ.,  Cambridge,  MA. 

Siklossy,  L.  [1974],  The  synthesis  of  programs  from  their  properties  and  the  insane  heuristic, 
Proc.  3rd  Texas  Conf.  on  Computing  Systems,  Austin,  TX. 

Sintsoff,  M.  [Jan.  1978],  Calculating  properties  of  programs  by  valuations  on  specific  models, 
Proc.  ACM  Conf.  on  Proving  Assertions  About  Programs,  Las  Cruces,  NM,  SIGPLAN 
Notices,  vol.  7,  no.  1,  pp.  203-207. 


180 


REFERENCES 


Standlsh,  T.A.,  D.C.  Harrlman,  D.F.  Klblar,  and  J.M.  Neighbors  [Fab.  1976],  Improving 
and  refining  program  by  program  manipulation,  Memo,  Dept,  of  Information  and  Computer 
Science,  Univ.  of  California,  Irvine,  CA. 

Sussman,  G.J.  [1975],  A  computer  mode I  of  skill  acquisition,  American  Elsevier,  New  York, 
NY. 

Suzuki  N.  and  K.  Ishihata  [Jan.  1977],  Implementation  of  an  array  bound  checker,  Conf. 
Rec.  4th  ACM  Symp.  on  Principles  of  Programming  Languages,  Los  Angeles,  CA,  pp. 
132-143. 

Tamir,  M.  [Aug.  1976],  ADI  -  Automatic  derivation  of  invariants,  Master's  thesis, 
Weizmann  Institute  of  Science,  Rehovot,  Israel. 

Teitelman,  W.  [1974],  INTERLISP  reference  manual.  Xerox  Research  Center,  Palo  Alto, 

CA. 

Ulrich,  J.W.  and  R.  Moll  [Aug.  1977],  Program  synthesis  by  analogy,  Proc.  ACM  Symp.  on 
Artificial  Intelligence  and  Programming  Languages,  SIGPLAN  Notices,  vol.  12,  no.  8, 
Rochester,  NY,  pp.  22-28. 

Waldinger,  R.J.  [1977],  Achieving  several  goals  simultaneously.  In  Machine  Intelligence  8: 
Machine  Representations  of  Knowledge  (E.W.  Elcock  and  D.  Michie,  eds.),  Ellis  Horwood, 
Chichester,  England,  pp.  94-136. 

Waldinger,  R.J.  and  K.N.  Levitt  [Fall  1974],  Reasoning  about  programs.  Artificial 
intelligence,  vol.  6,  no.  3,  pp.  235-316. 

Warren,  D.H.D.  [July  1976],  Generating  conditional  plans  and  programs,  Proc.  Conf.  on 
Artificial  Intelligence  and  Simulation  on  Behaviour,  Edinburgh,  Scotland,  pp.  344-354. 

Water*,  R.C.  [July  1977],  A  method,  based  in  plans,  for  understanding  how  a  loop 
implements  a  computation,  Working  paper  150,  Artificial  Intelligence  Laboratory,  MIT, 
Cambridge,  MA. 

Wegbreit,  B.  [Feb.  1974],  The  synthesis  of  loop  predicates,  CACM,  vol.  17,  no.  2,  pp. 
102-112. 

Wegbreit,  B.  [Sept.  1976],  Property  extraction  in  well-founded  property  sets,  lEE^I  Software 
Engineering,  vol.  SE-1,  no.  3,  pp.  270-285. 

Wegbreit,  B.  [Jan.  1976],  Goal-directed  program  transformation,  Conf.  Rec.  3rd  ACM  Symp. 
on  Principles  of  Programming  Languages,  Atlanta,  GA,  pp.  153-1 70. 

Wegbreit,  B.  and  J.M.  Spitzen  [Apr,  1976],  Proving  properties  of  complex  data  structures, 
JACM,  voi.  23,  no.  2,  pp.  389-396. 

Wensley,  J.H.  [Jan.  1959],  A  class  of  non-analytical  Iterative  processes,  Computer  J.,  vol.  1, 
no.  4,  pp.  163-167. 

Wilber,  B.M.  [Mar.  1976],  A  QLISP  reference  manual,  Technical  note  118,  Artificial 
Intelligence  Center,  SRI  International,  Menlo  Park,  CA. 


Wirth,  N.  [1973],  Systematic  programming:  An  introduction,  Prentice -Hall,  Englewood  Cliffs, 
NJ. 

Wirth,  N.  [Dec.  1974],  On  the  composition  of  well -structured  programs.  Computing  Surveys, 
voi.  6,  no.  4,  pp.  247-26 9. 

Yelowits,  L.  and  A.G.  Duncan  [Aug.  1977],  Abstractions,  instantiations  and  proofs  of 
marking  algorithms,  Proc.  Conf.  on  Artificial  Intelligence  and  Programming  Languages, 
SIGPLAN  Notices,  vol.  12,  no.  8,  Rochester,  NY,  pp.  13-21. 


182 


LIST  OF  PUBLICATIONS 


(partially  supported  by  grant  AFOSR-78-3483) 

Journals  and  Conference  papers: 

Dershowitz,  N.  and  Z.  Manna  [Nov.  1977],  The  evolution  of  programs:  A  system  for 
automatic  program  modification,  IEEE  Transactions  on  Software  Engineering,  Vol.  SE-3,  No. 
6.  Also  presented  at  the  ACM  symposium  on  principles  of  Programming  Languages,  Los 
Angeles,  Jan.  1 977. 

Dershowitz,  N.  and  Z.  Manna  [May  1978],  Inference  rules  for  program  annotation. 
Proceedings  of  the  Third  International  Conference  on  Software  Engineering,  Atlanta,  GA. 

Dershowitz,  N.  and  Z.  Manna  [And*  1979],  Proving  termination  with  multiset  orderings, 
CACM,  Vol.  22,  No.  8. 


Theses: 

Netzer,  I.  [April  1976],  Logical  analysis  of  recursive  programs.  Master's  thesis,  Weizmann 
Institute. 

Tamir,  M.  [Aug.  1976],  ADI:  automatic  derivation  of  invariants.  Master's  thesis,  Weizmann 
Institute.  Also  presented  at  the  Computer  Science  Conference,  Atlanta,  GA,  Jan  1977. 

Sagiv,  Y.  [Aug.  1976],  A  study  of  the  automatic  debugging  of  programs.  Master's  thesis. 
Weizmann  Institute. 

Fried,  R.  [Feb.  1977],  A  multi-processing  control  structure  to  facilitate  search  methods  for 
QLISP  goal -trees,  Master's  thesis,  Weizmann  Institute. 

Weingarten,  Y.  [May  1978],  Intermittent  assertion  proof  schemes.  Master's  thesis, 
Weizmann  Institute. 

Dershowitz,  N.  [Nov.  1976],  The  evolution  of  programs,  Ph.D.  thesis,  Weizmann  Institute. 

Technical  Reports: 

Raim,  M.  [Oct.  1976],  The  QLISP/ 370  reference  manual,  Technical  report,  Weizmann 
Institute. 

Raim,  M.  [May  1977],  A  guide  to  INTERLISP /i10,  Technical  report,  Weizmann  Institute. 

Raim,  M.  [July  1977],  The  QLISP  transplant  operation,  Technical  report,  Weizmann 
Institute. 


